Дизайн, управляемый доменом, и дизайн, управляемый базой данных, для веб-приложения MVC

Я расширяю / преобразовываю устаревшее приложение Web Forms в совершенно новое приложение MVC. Расширение касается как технологий, так и бизнес-использования. Устаревшее приложение - это хорошо сделанный Database Driven Design (DBDD). Так, например, если у вас есть разные типы сотрудников, такие как Operator, Supervisor, Store Keeper и т. Д., И вам нужно добавить новый тип, вы просто добавляете несколько строк в пару таблиц и вуаля, в вашем пользовательском интерфейсе автоматически есть все для добавления / обновить новый тип сотрудника. Однако разделение слоев не так хорошо.

Новый проект имеет две основные цели

  • Расширяемость (для текущих и будущих требований к трубопроводам)
  • Спектакль

Я намереваюсь создать новый проект, заменив конструкцию на основе базы данных (DBDD) на конструкцию на основе домена (DDD), учитывая требования расширяемости. Однако переход от проектирования на основе баз данных к проектированию на основе доменов, по-видимому, оказывает обратное влияние на требования к производительности, если я сравниваю его с производительностью устаревшего приложения DBDD. В унаследованном приложении любой вызов данных из пользовательского интерфейса будет напрямую взаимодействовать с базой данных, а любые данные будут возвращаться в форме DataReader или (в некоторых случаях) DataSet.

Теперь при наличии строгого DDD любой вызов данных будет направляться через бизнес-уровень и уровень доступа к данным. Это будет означать, что каждый вызов будет инициализировать бизнес-объект и объект доступа к данным. На одной странице пользовательского интерфейса могут потребоваться разные типы данных, и, будучи веб-приложением, каждая страница может запрашиваться несколькими пользователями. Кроме того, веб-приложение MVC, не имеющее состояния, каждый запрос должен каждый раз инициализировать бизнес-объекты и объекты доступа к данным. Таким образом, кажется, что для приложения без сохранения состояния MVC DBDD предпочтительнее DDD для производительности.

Или в DDD есть способ добиться как расширяемости, которую обеспечивает DDD, так и производительности, которую обеспечивает DBDD?

Источник

3 ответа

Решение

Рассматривали ли вы какую-либо форму разделения командных запросов, когда обновления выполняются в рамках модели предметной области, а чтение выполняется как DataReaders? Полноценный DDD не всегда уместен.

Источник

"Теперь со строгим DDD любой вызов данных будет направляться через бизнес-уровень и уровень доступа к данным".

Я не верю, что это правда, и это, конечно, не практично. Я считаю, что это следует читать:

Теперь со строгим DDD любой вызов для транзакции будет направляться через бизнес-уровень и уровень доступа к данным.

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

  1. Время - вам понадобится НАМНОГО дольше для реализации функциональности, без какой-либо выгоды.
  2. Дизайн модели - модель вашего домена будет изогнута, чтобы соответствовать запросам, а не поведению.
  3. Производительность - не из-за дополнительного уровня, а потому, что вы не сможете получить агрегированные данные из вашей модели так быстро, как вы можете непосредственно из запроса. Т.е. учитывайте общую стоимость всех заказов, размещенных для конкретного клиента - гораздо быстрее написать запрос для этого, чем выбрать все объекты заказа для клиента, выполнить итерацию и суммирование.

Как упоминал Chriseyre2000, CQRS стремится решить именно эти проблемы.

Источник

Использование DDD не должно иметь значительного влияния на производительность в вашем сценарии. То, о чем вы беспокоитесь, больше похоже на проблему доступа к данным. Вы ссылаетесь на это как

инициализировать бизнес-объект и объект доступа к данным

Почему "инициализация" стоит дорого? Какие механизмы доступа к данным вы используете?

DDD с долгоживущими объектами, хранящимися в реляционной базе данных, обычно реализуется с помощью ORM. При правильном использовании ORM практически не окажет влияния на производительность для большинства приложений. И вы всегда можете переключить обратно наиболее чувствительные к производительности части приложения на необработанный SQL, если есть проверенное узкое место.

Что бы это ни стоило, NHibernate нужно инициализировать только один раз при запуске приложения, после чего он использует тот же пул соединений ADO.NET, что и ваши обычные устройства чтения данных. Таким образом, все сводится к правильному отображению, выбору стратегии и избеганию классических ошибок доступа к данным, таких как "n+1 выбор".

Источник
Другие вопросы по тегам