Сущности: Это мои классы, которые сопоставлены с таблицами в базе данных, такими как Пользователь, Транзакция, Заказ и так далее. Это объекты POCO (и я использую их с подходом Code-First).
Модель предметной области: Это место, где должна находиться бизнес-логика. Мне потребовалось довольно много времени, чтобы понять, что модель предметной области не совпадает с названиями EF.
Уровень обслуживания: Я понял, что уровень обслуживания вообще не нужен. Его можно использовать для внесения в него чего-то, но в целом бизнес-логика должна быть в модели. Так что лучше оставим это
Repository-Layer: Хорошо, мы можем написать репозиторий с помощью CRUD-методов, таких как IEnumerable GetUsers(), которые упрощают тестирование, но с другой стороны, мы потеряем все функции LINQ, и придется писать гораздо больше. Для тестирования я также могу имитировать EF Framework, поэтому для меня уровень репозитория отсутствует.
Единица работы: Сам DbContext является единицей работы. Поэтому мне не нужно здесь писать ничего особенного, мне просто нужно передать DbContext всем моим методам и после завершения вызвать SaveChanges.
Отложенная загрузка: Иногда я использовал ее, иногда я использовал Eager Loading. Но тем временем я понял, что отложенная загрузка необходима, если вы хотите выполнять работу с единицами работы и поддерживать чистоту своего кода. Когда вы находитесь в методе и получаете некоторый код, переданный в него из другого метода, который, в свою очередь, получил его из другого метода... вы просто хотите получить доступ к свойствам. Вам все равно, есть ли там данные или нет. Он должен загружаться автоматически. Поэтому мне интересно, как это сделать без отложенной загрузки.
DbContextScopes: Как и в других обсуждаемых сообщениях, нам не следует использовать DbContext для экземпляра приложения, мы также не должны использовать его для каждого запроса. Вместо этого нам следует создать один DbContext для текущей задачи и передать его всем необходимым методам. Это можно упростить, используя [DbContextScopeFactory][1].
Внедрение зависимостей: Мне всегда следует использовать внедрение зависимостей для внедрения необходимых данных в конструктор. Это имеет смысл, потому что, когда у нас есть модульный тест, мы можем просто добавить макетные ресурсы. Я также читал, что внедрение атрибутов не так уж и хорошо и его не следует использовать.
Транзакции: больше не следует использовать, поскольку с ними много проблем. Вместо этого придерживайтесь Unit-Of-Work (который внутри использует транзакцию?!) и моделируйте свою архитектуру таким образом.
И теперь мне интересно, как на самом деле использовать эту штуку.
Вопрос 1: Модель = Сущность?
Должны ли мы создать какую-то отдельную модель предметной области или можно ли включить ее в модель сущности? Я думаю, что дополнительная модель предметной области требует много кода. Почему бы не записать логику в сущности? В чем проблемы?
Вопрос 2: Как получить DbContext?
Когда я добавляю объект, я не хочу добавлять такие элементы инфраструктуры, как
Код: Выделить всё
order.Lines.Add(new OrderLine(product, qty, text));
Код: Выделить всё
order.Lines.Add(new OrderLine(dbcontext, product, qty, text));
