О выборе платформы для новых проектов

[metaclass]

Вот тут ребе belnetmon спрашивает совета про выбор платформы для новых проектов. Для проектов типа GUI или типа веб. Там в комментах советуют всякое страшное, но не в этом суть.

Что-то меня вообще такая формулировка вопроса смущает. Основная проблема при переходе с используемых платформ на новые - это то, что "все нужно переделывать". Вот, к примеру, я как-то попытался повторить идеи, использумые в софте на дельфи (обобщенный MDI-клиент для Firebird), на дотнете (сделать клиент к произвольной реляционной БД). Оно вообще получилось и работает. Но поголовно "все не так". Не так работают дата-гриды, не та модель работы с данными, непонятно, что использовать в качестве генератора отчетов, итд.


Если переходить на что-то еще менее привычное - предвижу всякое безумие, в плане того, что обязательно чего-нибудь привычного будет не хватать. Вот к примеру кроссплатформенная библиотека для RS232. Советуют boost.asio, но там нету ручного управления линиями(в документации с первого раза я это не нашел). Потому, что "никому не надо". И так, скорее всего, будет со всем. По опыту - будут библиотеки для любых целей, но конкретно мои задачи будут требовать от них каких-то функций, которых нет, потому что "никому не нужны".

Т.е., вопрос не "какую платформу выбирать", а "что выбрать, чтобы перейти с наименьшим напрягом, чтобы были библиотеки, чтобы потом было где искать разработчиков, и чтобы это не остановило всю работу".

Comments

[volodymir-k.livejournal.com]

> Основная проблема при переходе с используемых платформ на новые - это то, что "все нужно переделывать".

Проблема ли это? РФ-РБ переползла с технологий и потребления СССР на общеевропейское, за каких-то 10 считай лет. Очень много старого выбросили и заменили новым. И ничего. Рутина.

> Не так работают дата-гриды, не та модель работы с данными

Это есть. Но в целом тот Дельфи паттерн Table Gateway и был уродлив.
Сдох -- и хорошо.

> что использовать в качестве генератора отчетов

Ну даёте. Аксесс, конечно! :)
У МС есть крайне мощный репорт сервер.

> что выбрать, чтобы перейти с наименьшим напрягом, чтобы были библиотеки, чтобы потом было где искать разработчиков, и чтобы это не остановило всю работу

В этой задаче хорошо бы подошли типа профсоюзов или профобъединений. Типа "союз пчеловодов нижней Саксонии". Ваша ниша узкая, и Вы похоже оторваны от коллег. А в других нишах всё проще, обычно есть типовые технологии.

Если считаете, что нет библиотек -- а как тогда зарубежные товарищи аналоги делают? Если технология реально устарела -- может и хрен с ним. Зачем RS232 если вовсю USB и bluetooth.

[metaclass.livejournal.com]

Дельфийский паттерн в некотором роде был странный, да. Но по какой-то причине, на нем всегда получалось делать лучше, чем на ADO.NET датасетах. Даже в плане любого расширения существующей функциональности - в дельфи, при отсутствии рефлекшена, ComponentModel, сборщика мусора - расширять Dataset и DBGrid намного проще - как-то более правильно спроектировано все.

Access у клиентов может банально не быть. MSSQL с его репортинг сервисес тоже. Тут и так софт за собой тянет какую-то гору зависимостей, постоянно у клиентов то MDAC обновлять приходится, то дотнет, то iis перенастраивать.

Насчет типовых технологий - вот я тоже считаю, что они должны быть. А судя по комментариям - кто во что горазд.

А аналоги делаются просто. Самописанные библиотеки используются в основном. У нас в проекте есть железо с RS232, USB(HID), есть беспроводное с проприетарным приемником и протоколом, будет и блютуз вроде. Везде - только ручное написание, безальтернативно. "Никто такого больше не делает".

[volodymir-k.livejournal.com]

> в дельфи, при отсутствии рефлекшена, ComponentModel, сборщика мусора - расширять Dataset и DBGrid намного проще - как-то более правильно спроектировано все

Думаю, мы говорим о разном. Я говорю о том, что доступ "под капотом" у датасета был через insert/post, было понятие "текущая запись". Это наследие DBF, в начале 90-х на нём и аналогах были написаны все "опердени". Уже в 1993, помнится, читал в компьютерных газетах стенания, что вот при переходе на Настоящие Сетевые БД С Настояшщим SQL всё это великолепие надо будет поломать. И вот, прошло всего лет 7, и всё поломали. )))

Вы говорите про design time -- да, реализовать банальный драг-н-дроп с кучей дельфийских фич из популярных никто не смог (хотя например в 2001 я лично писал веб-фреймворк на Ж2EE с хорошей интеграций ЖСП кода с неким сторажом -- да всё сдохло). Возможно, причина и в процессорах, тогда ява была медленная.

А сейчас как-то у народа в мозгах концепция поменялась, что надо именно наследоваться вместо параметризации. Времени убивается куча. Ради справедливости, в дельфях тоже была такая лажа, что если поля БД хочешь именованные как проперти, то... там довольно нетривиальное вуду.

> Access у клиентов может банально не быть.

Есть у них специально для этого рантайм система. Тянется готовый экзешник с ДЛЛ и МДБ файлом, ничего не надо ставить, просто копируешь файлы. Для защиты от разбора там есть фича с паролем разработчика и вообще правами.

У меня есть книга про адвансед программирование на аксессе (на рус.), так это мегатул вообще. Почти дельфи, только компонент мало.

> А судя по комментариям - кто во что горазд.
> Везде - только ручное написание, безальтернативно. "Никто такого больше не делает".

Думаю, Вы не там смотрите. Во-первых ЖЖ всё таки не для профессионалов. Во-вторых, насчёт уникальности как-то не верю. В ЕС-Китае-США техникой занимается куча людей.

[metaclass.livejournal.com]

Insert/post очень просто и прозрачно делается на sql-базах данных. В датасете просто указаны select, insert, update, delete-запросы и список первичных ключей.

Drag-drop дельфийский почти не нужен. Я им не пользуюсь уже лет 5, хотя половина кода на дельфи. Все что касается гридов и датасетов - генерится в рунтайме из метаданных базы.

[vp.livejournal.com]

Это есть. Но в целом тот Дельфи паттерн Table Gateway и был уродлив.
Сдох -- и хорошо.

Может речь о модели с курсорной обработкой данных?

[volodymir-k.livejournal.com]

да

[vp.livejournal.com]

У курсорной обработки данных ноги росли из разных клипперов-фокспро. Факт, что целому поколеню программеров это сломало моск, бесповоротно :(