![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Пятничный спор.
В общем, изучение ФП и около того окончательно привело к тому, что я не могу нормально занятся решением прикладных задач.
Сидим с ребе![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
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 страницам теоретического обоснования, из которого все остальное выводится элементарно.
Сидим с ребе
belnetmon и пытаемся решить, как правильно реализовать своими силами очередную распределенную опердень и не сойти с ума.Вроде бы сошлись на том что
Насчет базы данных уже не так ясно - то ли Firebird, то ли Postgresql, но первоначальная идея, что на конкретную базу завязываться не стоит. Но тут уже всплывает первая проблема - распределенность опердени означает синхронизацию баз, а синхронизация баз означает наличие логов изменения всего чего только можно в базе и накатывание этих логов на другие базы(или же наличие для базы родных средств репликации). Т.е. немелкий кусок функциональных требований оказывается в базе и влияет на ее выбор.
Потом начинается следующая хрень: есть две вариации этой опердени - глобальная с трехзвенкой (ну тупо пустить всю работу по HTTP более удобно чем лезть напрямую в базу клиентом) и локальная двухзвенная (поднимать IIS на компе с ограниченным функционалом и сертифицируемым софтом совершенно нет желания). Но базы данных должны быть идентичны, и клиентская часть в плане GUI желательно должна быть реализована на одной и той же основе, потому что нужны одни и те же функции работы с db-centric приложениями (отчеты, печать, фильтры, сортировка, итд).
А вот дальше начинается спор на тему: как лучше делать?
Мне проще
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 страницам теоретического обоснования, из которого все остальное выводится элементарно.
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
Цель - строгая типизация в том числе и на уровне БД.
no subject
no subject
спаси невинные души!
no subject
no subject
Другое дело, что я этот вариант уже где-то на треть реализовал и в продакшен старый сунул, и у меня практически всегда разработка "как мне удобнее", а не "как предсказуемее по срокам" получается быстрее и качественнее.
no subject
no subject
Вроде, Slony под PostgreSQL уже умеют мастер-мастер-репликацию.
no subject
http://wiki.postgresql.org/wiki/Replication%2C_Clustering%2C_and_Connection_Pooling#Comparison_matrix
no subject
Ну да, я больше про то, что есть такое, и уже вполне продакшн (?)
no subject
Мне кажется, основная часть целевой аудитории, для которой они пишутся, просто неспособна усвоить 50 страниц теоретического обоснования. Это те самые индусы, которые задают тупейшие вопросы на девелоперских форумах микрософта и которые не способны воспринять полученный ответ, если только он не соответствует в точности их потребностям (имена объектов, переменных и т.д.).
Для себя я нашел способ добраться до объяснений внутреннего устройста системы, которое зачастую объясняет все остальное - чтение блогов разработчиков. А книжки я покупаю только для того, чтобы подготовиться к сертификационным экзаменам.