Пятничный спор.

В общем, изучение ФП и около того окончательно привело к тому, что я не могу нормально занятся решением прикладных задач.

Сидим с ребе belnetmon и пытаемся решить, как правильно реализовать своими силами очередную распределенную опердень и не сойти с ума.
Вроде бы сошлись на том что ежики, кактус пишем на .NET 3.5, т.к. в наших виндовых палестинах это более-менее мейнстрим.
Насчет базы данных уже не так ясно - то ли Firebird, то ли Postgresql, но первоначальная идея, что на конкретную базу завязываться не стоит. Но тут уже всплывает первая проблема - распределенность опердени означает синхронизацию баз, а синхронизация баз означает наличие логов изменения всего чего только можно в базе и накатывание этих логов на другие базы(или же наличие для базы родных средств репликации). Т.е. немелкий кусок функциональных требований оказывается в базе и влияет на ее выбор.
Потом начинается следующая хрень: есть две вариации этой опердени - глобальная с трехзвенкой (ну тупо пустить всю работу по HTTP более удобно чем лезть напрямую в базу клиентом) и локальная двухзвенная (поднимать IIS на компе с ограниченным функционалом и сертифицируемым софтом совершенно нет желания). Но базы данных должны быть идентичны, и клиентская часть в плане GUI желательно должна быть реализована на одной и той же основе, потому что нужны одни и те же функции работы с db-centric приложениями (отчеты, печать, фильтры, сортировка, итд).


А вот дальше начинается спор на тему: как лучше делать?

Мне проще закатить солнце вручную наклепать (вернее оно уже частично сделано для других проектов) некий DSL для моделей и генерации из них кода, потом запилить всю предметную область в модель и из нее сгенерировать следующее:

1) Схему БД(таблицы, view на них, таблица логов изменений, запросы, итд)
2) ORM-маппинги (то ли руками, то ли используя NHibernate или тому подобное)
3) Метаданные для GUI (подписи полей, справочники, форматы полей ввода

Для сложных расчетных алгоритмов использовать до кучи LINQ и F# как наиболее лаконичный способ выражать всякую безумную логику. Кодогенератор тоже сделан на F#.


Альтернативный вариант: все по максимуму делать на "готовых" технологиях: Entity Framework, LINQ, чисто C#, т.е. условно говоря, пытаться следовать в мейнстриме. Я примерно представляю, зачем это нужно - на готовые технологии потом проще найти людей на поддержку.
Но у меня при работе с .NET по жизни получается такая хрень: использование "готовых" технологий постоянно упирается в какие-то тупики в силу того, что эти высокоуровневые библиотеки разработаны какими-то не совсем вменяемыми индусами в микрософте, да еще сверху ими командуют вообще невменяемые маркетологи и менеджеры. И приходится городить костыли, сидеть в рефлекторе, копаться в исходниках, итд.

И второе, что меня в этом варианте напрягает - готовые варианты создания моделей предметной области покрывают только малую часть требуемых функций, например "только ORM и запросы к объектам". А мне нужны еще поддержка физической и логической версионности объектов, метаданные для GUI и сериализации объектов и в итоге получается, что даже объекты предметной области или превращаются в кошмар типа "одна проперть и 20 строк атрибутов для разных аспектов использования" и работать с этим невозможно, или объект приходится дублировать N раз, наследуя от базового интерфейса и делая типа "объект для работы в GUI, объект для загрузки из БД, объект для сериализации и таскания объекта по HTTP" и так далее.

Для подобных вещей существуют готовые инструменты (AOP, всякие там генераторы объектов-прокси, и прочая, и прочая), но мне кажется, что самодельный кодогенератор, выдающий на выход тупой код аналогичный написанному вручную по строгой спецификации сотней обезъян-аутсорсеров будет удобнее - такой код проще отлаживать, чем читать адские стеки вызовов работа которых зависит от десятков атрибутов разных классов и объектов.



PS: Вот еще что бесит в "готовых" технологиях. Книжка по каждому частному случаю частного фреймворка - 1000 страниц разливания воды, стандартно. Без теории, что характерно, исключительно "частные решения частных проблем". А потом это все дело забросят (как CORBA, ActiveX, COM, итп), и прочитанный бред окажется бесполезным. Я предпочитаю изучать и работать "от первых принципов", т.е. от теории, потому что 1000 страниц частных случаев бреда сводится к 50 страницам теоретического обоснования, из которого все остальное выводится элементарно.