|
Честно говоря я так и не вьехал в суть спора :) Раз PBVM под DataWindow.NET ставиться, то это старый обычный ActiveX DataWindow, обернутый интерфейсами .NET, что есть хорошо: очень высокая скорость работы и низкая требовательность к ресурсам, в отличие от чистых .NET компонентов (меня всегда веселило, что QuantumGrid.NET или UltraGrid.Net тормозят со страшной силой при отрисовке и кушают по 30 метров памяти, хотя с другой стороны оно и понятно - идеология сборщика мусора в GUI - на этом еще и Java споткнулась неплохо). С другой стороны если посмотреть, то толку от DW.NET тоже не особо много - небось он со своим Transactional object работает и ему ADO.NET побоку ? :) Если это так, то я бы назвал DW.NET чисто маркетинговым ходом, как говориться сделали, чтобы было и никто не мог Sybase заявить, что они отстали от модных MS технологий. С учетом того, что ADO.NET не так уж и плох, да и ко всему прочему по принципам кое в чем содран с принципов DataStore, а кое в чем даже неплохо расширен, то думаю что MS публика предпочтет использовать его вместе с гридами .NET.
Лично я считаю, что кстати .NET вообще не катит под написание мордочек под БД. Веб лепить вот милое дело, а GUI делать на нем - чистейшей воды мазохизм (так же, как в Delphi и Java). Меня например именно своей мощностью DW, простотой реализации ООП и PowerScript, прозрачным элегантным доступом к данным и встроенным SQL и привлекает PB. По моему здесь все четко и красиво (пусть и со своими грехами), в отличие от универсальных средств 3 в одном, где через одно можно все, но только через заднее место.
авторDW, что еще есть в PB такого же ценного? Все остальное мелочи, из-за которых даже споры разводить не интересно.
Я вот к примеру вчера ровно за 20 минут забабацал себе на PB компонент для организации сложных окон-визардов, причем получилось все красиво в рунтайме и удобно в дизайнтайме. Немножно повозил мышкой, немножко кода пописал (порядка 50 строчек несложного кода) и вуаля. На Delphi подобный компонент-визард я лепил порядка 4 дней, никакой мышки - голый код (500 строк), плюс еще использование WinApi для корректной отрисовки компонентов VCL с переключающихся страничек, так как сами они глючили вследствие того, что Delphi не всегда правильно обрабатывал сообщения WINAPI. Плюс потом умучался отлаживать все это дело в дизайн и рунтайм режимах. Сюда до кучи можно вспомнить POST-обработку событий и методов в PB, в отличие от Delphi, в котором приходиться в классе формы (или обьекту с handle) прописывать метод MESSAGE с собственным кодом сообщения, в нем прописывать необходимую пост-обработку, а далее его использовать для вызова через функцию WinApi POSTMESSAGE. Ну и встроенный SQL ту да же до кучи: вся суета на выполнения SQL через компонентную технологию сильно напрягает, SQL в виде стринга занеси, параметры ручками определи, и т.д. Можно конечно на формочки на каждый используемый SQL компонент кидать и в визуале его рисовать, но возникает закономерный вопрос - а не жирно ли из за вызова например одной ХП держать на время жизни формы лишний обьект (опять же это наиболее будет актуально для Java и C#).
авторК сожалению, в ЛЮБОМ крупном проекте есть 10-20% "тяжелых" алгоритмов, которые отравляют жизнь.
Ммм ... вроде давно уже всякие крупные 2-звенные проекты пишу (пусть и не так давно на PB), но вот ни разу на эти 10-20% не наталкивался. Все у меня как то тяжелые алгоритмы или на СУБД уведены или если уж чего то специфическое, то всегда DLL/COM/OLE написать не долго хотя бы на том же Delphi. Так что в клиентской части у меня кроме интерфейсной части и примитивной клиентской бизнес-логики ничего и нет. Может быть приведете примеры тяжелых алгоритмов в клиентском приложении ?
IMHO Для рисования мордочек .NET бесполезен, как и Java. Возможностей вроде как много, требований к ресурсам и геммору честно говоря не меньше, чем этих возможностей. Я вот например сейчас катаю проект на ASA + PB. Начальные требования к аппаратной части клиента:
сервер+клиент: P2 Celeron 300 mz, 32 RAM
клиент: P2 Celeron 300 mz, 16 RAM
Задачка навороченная, с сложными расчетами и данных кстати не так мало будет. Как Вы думаете, насколько мне бы пришлось увеличить начальные требования к аппаратной части, если бы я заменил ASA на будующий MSSQL Якон или же PB на C# ? Думаю как минимум что то типа:
сервер+клиент: P3 1гц, 256 RAM
клиент: P3 1гц, 128 RAM
Для тиражного ПО, требованием к которому выставляется возможность работы от мелких до крупных клиентов, такая конфигурация не приемлима.
|
