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

[metaclass]

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

Сидим с ребе 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 страницам теоретического обоснования, из которого все остальное выводится элементарно.

Comments

[norguhtar.livejournal.com]

Вы таки не пробовали Spring?

[ex-vdom.livejournal.com]

Касательно базы, для полноты ощущений можно попробовать свежую бету 9 постргреса с поддержкой репликации.

[denisioru.livejournal.com]

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

[mr-aleph.livejournal.com]

просверли функциональщика перфоратором

спаси невинные души!

[nivanych.livejournal.com]

> означает синхронизацию баз

Вроде, Slony под PostgreSQL уже умеют мастер-мастер-репликацию.

[ennor.livejournal.com]

Насчет 1К страниц воды в книжках.

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

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