Предположим, у вас есть три уровня (с пространствами имен):
- Пользовательский интерфейс (
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 непосредственно в Views, LINQ 2 Entites также не создает POCO как таковые ...
Итак, при использовании любого автоматизированного кода для генерации мы должны использовать объекты DAL или вручную кодировать наши общие POCOs? Первая часть выглядит как простой выход но не отделяет DAL от пользовательского интерфейса (и может иметь проблемы с безопасностью и масштабируемостью позже), второй подвержен ошибкам и очень утомителен для базы данных среднего размера.
Что бы вы предложили?