Здравствуйте, Аноним, Вы писали:

А>Вот я с 5 класса писал программы на паскале, потом Си потом... чего там только не было. С ростом сложности програм меня всегда мучала мысль — как написать красивое и масштабируемое приложение. Думаю грабли у всех одни и те же: процедуры/функции, затем ООП, затем патерны. Вдруг я понял что сценарий транзакции или шлюз таблицы хорош только в примитивных приложениях (ИМХО!!!).

Не примитивные приложения, а приложения с примитивным состоянием, т.е. без него.

А>На сегодняшний день я не нашел более действенного метода нежели Domain Driven Design. Поэтому диктат тут не орээмами а методологией.

Безусловно DDD где-то рулит, а где-то рулит не очень, где-то не рулит совсем. Поэтому, одной методологией ограничиваться не разумно. Любая методология — это всего лишь на всего инструмент, такой же как паттерны, языки, библиотеки, ORM и т.п. Даже ООП можно рассматривать как всего лишь набор паттернов. А раз это инструмент, то место ему в коробке с другими инструментами, а не в углу в иконе. Подходит в каком-то случае лучше DDD — берём DDD, подходит Singleton — берём Singleton. Единственное требование к инструменту — это чтобы он, решая мои определённые проблемы, не создавал других в количестве, превышающем полезный выхлоп от его применения. Подход H/ORM, в котором всё уже как бы сделано и смешано в одном флаконе, для меня такие проблемы создаёт. Сделано то оно сделано, только не всегда хорошо и не всегда под мои нужды.

А>Скажи пожалуйста — какой фундамент у твоих разработок? Строишь ли десктоповые приложения?

Не совсем понял насчёт фундамента. По поводу десктопов — да, всего хватает: веб, процессинг, сервисы, десктоп в том числе. Но судя по упомянутому тобой DDD, речь скорее должна идти не конкретно о десктопах, а о приложениях, интенсивно работающих с собственным состоянием. Таким приложением может быть не только десктоп, а практически всё. Даже в вебе встречаются навороченные формы с развесистым состоянием и народ до сих пор мечется в поисках истины между AJAX, распределённым состоянием типа ViewState в ASP.NET и сильверлайтами. В результате удивляясь почему у них плохо работает и то и другое и третье.

А ответ прост — выбирать технологию нужно не для приложения в целом, а для каждой отдельной подзадачи из соображений обработки состояния в этой подзадаче. И всё сразу становится на свои места. Для страниц, не требующих интеррактива с пользователем характерны прямые запросы к базе, часто хитровыгнутые и с ad-hoc результатом. Запросил, нарисовал, забыл. Какое здесь может быть состояние? Зачем тут DDD? Зачем тяжелые ORM и прочие пляски вокруг объектных моделей? Зачем AJAX и сильверлайт? Для навороченных форм ввода без AJAX и сильверлайтов, наоборот, обойтись можно, но сложно, т.к. приходится работать с распределённым между клиентом и сервером состоянием. Здесь, безусловно, рулят объектные модели.

При этом наибольшая гибкость достигается, если объектная модель приложения отделена от модели данных. Причём чем сложнее состояние, тем больше проявляется этот эффект. Модель данных как правило быстро устаканивается и меняется редко. В свою очередь объектная модель затачивается под состояние, его обработку и отображение и в результате подвержена изменения практически всё время жизни приложения.

В общем, задачи нужно делить не на web и desktop, а по типу работы с состоянием. А это можно условно разделить следующим образом:

1. Отсутствие состояния.
2. Простое состояние, которое практически соответствует модели данных приложения.
3. Сложное состояние.

С первым типом всё понятно — обычная stateless модель. Cyberax такие задачи называет примитивными LW/ORM для таких задач самое оно. H/ORM явно тяжеловата.

Со вторым тоже не сложно. Прямой маппинг модели данных в объектную модель и дальнейшая несложная работа с этой моделью — это то, на что H/ORM затачивается годами. У LW/ORM с маппингом тоже всё в порядке, определённые сложности имеются в части трекинга и сохранения изменений, но эти вещи с успехом можно решать независимо и/или другими способами.

С третьим типом тоже вроде всё без проблем. H/ORM тут только мешаются, а LW/ORM без разницы где рулить. Чтобы пояснить что я понимаю под этим типом состояния приведу в качестве примера одно из моих desktop приложений. В нём для хранения данных использовалась всего пара таблиц плюс справочники, а объектная модель представляла собой развесистую иерархическую структуру с трекингом и распространением изменения любого узла модели по всей модели. Главной проблемой была оптимизация распространения изменений. Т.к. всё это отображалось в гриде, то любая неоптимальность приводила к каскаду уведомлений и всё начинало жутко тормозить. А вот операции работы с базой сводились всего лишь к Load и Save, ну и подгрузка справочников.

Так вот. Если всё так хорошо, то непонятно где же могут возникать проблемы. Надеюсь применимость каждого вида ORM я очертил довольно чётко и это не вызывает сомнений. Если так, то нетрудно заметить, что проблемы у нас начинаются, когда H/ORM начинается перемещаться в ту или иную сторону.

Движение в сторону stateless модели приводит к утяжелению всего приложения, вместо хитровыгнутых и ad-hoc запросов, с которым лучше чем SQL сервер всё равно никто не справится, начинается полная или частичная загрузка объектной модели, что приводит к тормозам и неоправданному использованию ресурсов.

Но всё ещё хуже если движение идёт в сторону усложнения состояния. В этом случае H/ORM начинает тащить за собой и подгонять под состояние не только объектную модель приложения, но ещё и модель данных, т.к. по другому она не может (точнее может, но в строго ограниченных пределах). Отсюда у нас, кстати, возникают дурацкие требования к поддержке базой данных нереляционной ереси вроде наследования и иерархий. Вторая часть H/ORM — объектная модель тоже становится тормозом и проблемой, т.к. задачи в таких приложениях выходят за рамки просто оттрекал изменения и сохранил изменения. Гибкость объектной модели в таких приложениях — это всё, но гибкость эта ограничена H/ORM. В результате мы получаем приложение с переусложнённым дизайном БД и жёстко прибитой к ней негибкой объектной моделью.

А что же LW/ORM? А LW/ORM, как я уже сказал, без разницы где рулить. Она занимается только тем, что умеет делать хорошо и не вносит в дизайн приложения никаких искусственных ограничений. Единственная проблема — уровень подготовки разработчиков.