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

[metaclass]

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

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


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

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

Comments

[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, хотя половина кода на дельфи. Все что касается гридов и датасетов - генерится в рунтайме из метаданных базы.