Предположим, у вас есть три уровня (с пространствами имен):
- Пользовательский интерфейс (
App.UI) - вызывает процессы бизнес-уровня и общается с помощью объектов - Бизнес-уровень (
App.Core) - организует процессы и использует уровень DAL с помощью объектов. - DAL (
App.Data) - напрямую управляет хранилищем и сохраняет объекты
Допустим, у вас есть таблица User, которая отражена в вашем слое DAL в App.Data.User и, вероятно, также в App.Data.Users.
В вашем пользовательском интерфейсе есть представление, которое отображает пользователей приложения.
Чтобы действительно иметь разделенное (многоуровневое) приложение, у вас также должны быть App.Core.User и App.Core.Users, которые вам, вероятно, придется создать вручную.
лучшим решением (по моему мнению), конечно, будет: должен быть четвертый уровень Business Objects (App.Objects) с классами App.Objects.User и App.Objects.Users . Эти POCO будут использоваться на всех уровнях. Бизнес-уровню будет разрешено использовать только DAL, пользовательскому интерфейсу будет разрешено использовать только BL, но все они будут использовать App.Objects для общей объектной модели.
Шаблоны Asp.net MVC подразумевают использование объектов DAL непосредственно в представлениях, объекты LINQ 2 также не создают никаких POCO как таковых ...
Итак, при использовании любой автоматической генерации кода должны ли мы использовать объекты DAL или вручную жестко кодировать наши общие POCO? Первая часть кажется простым выходом но не отделяет DAL от пользовательского интерфейса (и в дальнейшем могут возникнуть проблемы с безопасностью и масштабируемостью), второй вариант подвержен ошибкам и очень утомителен при работе с базой данных среднего размера.
Что ты предлагаешь?
