Бизнес-логика в сущности и инъекции DbContext

Question

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

Сущности: Это мои классы, которые сопоставляются таблицам в базе данных, такие как Пользователь, Сделка, Заказ и т. Д. Это объекты POCO (и я использую их с помощью подхода Code-First).

Модель домена: Это место, где должна быть бизнес-логика. Мне потребовалось довольно много времени, чтобы модель домена не являлась саметом в качестве EF.

Service-Layer: Я понял, что сервисный уровень не нужен в первую очередь. Его можно использовать для приведения в него некоторых вещей, но в целом бизнес-логика должна быть в модели. Поэтому лучше проговорился

Repository-Layer: Ok мы можем написать репозиторий с CRUD-методы, как IEnumerable GetUsers(), которые делают тестирование проще, но с другой стороны, мы потеряем целые функции LINQ, и это много больше писем. Для тестирования я могу также высмеять EF Framework, поэтому для меня не существует слоя репозитория.

Unit-Of-Work: Сам DbContext является подразделением работы. Поэтому мне не нужно ничего кодировать здесь, мне просто нужно передать DbContext ко всем моим методам и вызвать SaveChanges по завершении.

Lazy-Loading: Иногда я использовал его, иногда я использовал Eage Loading. Но в то же время я понял, что Lazy-Loading - это необходимость, когда вы хотите сделать материал Unit-Of-Work и сохранить свой код в чистоте. Когда вы находитесь в методе и получаете некоторый код, который передается в это от другого метода, который, в свою очередь, получил это от другого метода ... вы просто хотите получить доступ к свойствам. Вам все равно, находятся ли данные или нет. Он должен загружаться автоматически. Поэтому мне интересно, как это сделать без какой-либо ленивой загрузки.

DbContextScopes: Как и в других обсуждаемых сообщениях, мы не должны использовать DbContext для экземпляра приложения, мы не должны также использовать его для запроса. Вместо этого мы должны создать один DbContext для текущей задачи и передать его всем необходимым методам. Это можно сделать проще с помощью [DbContextScopeFactory] [1].

Инъекция зависимостей: Я всегда должен использовать DI для ввода необходимых материалов в конструктор. Это имеет смысл, потому что, когда у нас есть единичный тест, мы можем просто добавить макет ресурсов. Я также читал, что инъекция атрибутов не так хороша и не должна использоваться.

Сделки: should'nt больше не используется, потому что у них есть много проблем. Вместо этого придерживайтесь Unit-Of-Work (который внутренне использует транзакцию ?!) и моделирует вашу архитектуру таким образом.

Так что теперь мне интересно, как реально использовать этот материал.

Вопрос 1: Модель = сущность?

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

Вопрос 2: Как получить DbContext?

Когда я добавить объект, то я не хочу, чтобы добавить инфраструктуры вещи, как

order.Lines.Add(new OrderLine(product, qty, text)); 

и не

order.Lines.Add(new OrderLine(dbcontext, product, qty, text)); 

Возможно приписывать инъекции зависимостей является решением, но, как сказал, что также не очень хорошая модель ...

Answer 1

Вопрос 1

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

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

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

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

Вопрос 2

В зависимости от того, что вы делаете (если вы не используете несколько потоков в запросе), как правило, вы должны иметь один новый DbContext для каждого запроса HTTP - это может быть сконфигурирован с использованием самых DI. Я бы установил get yourself an Interface for the DbContext и настроил его на вашем прикладном уровне MVC и ввел его вверх в ваш сервисный уровень.

...