Нужно ли использовать DDD, Unit of Work, Repositories или что-то подобное для простых веб-приложений?

Question

Я работаю над простой системой eCart с использованием .net4 (c #).Я много читал о модуле работы, шаблоне репозитория и невежестве постоянства.Я думаю, что у меня есть понимание стратегии и преимуществ для создания моих слоев таким образом, но для моего простого приложения мне интересно, если это необходимо, и если кто-то может указать мне на хорошую архитектуру для моей области.

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

Итак, вот вопрос -Я хочу, чтобы любая бизнес-транзакция, которая происходит, была сохранена в БД, как только она произошла, поэтому, похоже, нет смысла ставить в очередь данные в репозиториях, а затем сохранять их немедленно.Почему бы просто не сохранить его напрямую?

Существуют ли другие преимущества DDD, которые я упускаю , или было бы над созданием такой надежной архитектуры для каждого простого проекта, который приходит вместе??Спасибо за любую помощь.

Answer 1

Согласен с CodingGorilla. Шаблоны хороши, если они не конфликтуют с YAGNI .

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

Answer 2

Вам нужно , чтобы использовать [вставить шаблон здесь]: Нет Когда дело доходит до этого, наилучшей практикой всегда является то, что ваше приложение выполнено и соответствуетвремя, денежные и технические требования.

Но если вы воспользуетесь подходом «давайте просто сделаем это», то помните о технической задолженности , которую вы могли быимейте в виду.

Также есть много причин использовать некоторые из этих шаблонов (и они не всегда связаны с производительностью), в частности, шаблон Unit Of Work.Это больше связано с требованиями и ограничениями, которые часто приходят с ORM и тому подобным.Эти проблемы могут быть немного сложными, но я подозреваю, что когда вы начнете реализовывать некоторые из этих вещей, вы начнете понимать, что это за проблемы, и поймете, почему эти шаблоны полезны.