3-х уровневый - повторное использование моделей?

Question

Я создаю приложение, в котором есть три проекта:

ApiService (Web API 2)
BusinessLogic (Class Library)
DataAccess (Class Library)

• ApiService имеет ссылку на BusinessLogic
• BusinessLogic имеет ссылку на DataAccess

DataAccess использует Entity Framework с первым подходом к коду, поэтому он содержит модели для таблиц базы данных.

Мой вопрос: каков наилучший подход или наилучшая практика в отношении моделей для проектов в сфере бизнеса и услуг?

Я прочитал, что в сервисном проекте не должны использоваться модели проекта DataAccess, поэтому где я должен создавать эти модели в Сервисе или в бизнесе?

Заранее спасибо.

Answer 1

Отдельные BL(Business logic)/Presentation layer модели от DAL(Data access layer) моделей всегда.

Добавьте еще один слой между ними, который будет выполнять сопоставление, используйте Automapper или somethogn custom. Поэтому, когда вы передаете данные в DAL, модели будут сопоставлены с моделями сущностей, а когда BL получает данные из DAL, то же самое, сопоставьте модели сущностей с BL моделями,

Почему?

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

Answer 2

Я не знаю, является ли это наилучшей практикой, но я сделал много проектов, которые содержат много общей логики и функциональности между службами Windows, веб-API и т. Д. Все они следовали чему-то похожему на это:

Wrapper - содержит взаимодействия, модели и код для упрощения вызова WebAPI из другого проекта .NET. Не имеет ссылок на другие проекты вообще

Ядро - содержит всю мясную бизнес-логику.Сервисный уровень, уровень доступа к данным, вспомогательные классы и т. Д. References Wrapper и все остальное, что необходимо для работы

WebAPI - содержит только код, необходимый для создания WebAPI вокруг функций сервисного уровня в Core Ссылки Wrapper для моделей / интерфейсов и Core для бизнес-логики

Другие проекты, использующие Core, будут аналогичны WebAPI.Примерами могут служить консольное приложение для запланированных задач, служба Windows для непрерывной обработки данных и т. Д.

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