EF code-first, как использовать объекты POCO в клиентских слоях

Question

Я новичок в asp.net MVC и EF, поэтому извините, если мой вопрос непонятен или прост.

Я прочитал несколько руководств по поводу подхода EF Code-First, и теперь я пробую этот учебник Getting Started with EF using MVC.

Использование подхода Code-First Я использую классы POCO для определения моей модели БД, логики БД, проверки БД, проверки UI и некоторой логики пользовательского интерфейса. Поэтому я могу использовать эти классы (или объекты) на своем уровне представления или использовать их как объекты JSON при работе с веб-службами (или в JavaScript-коде).

Мой вопрос: Разве это не смешивает какую-то логику вместе? Я имею в виду, не следует ли использовать, например, класс классов представлений для презентации, и эти классы должны иметь логику и валидность?

Хорошая практика - отправить объект POCO на представление (или клиенту в целом)?

Наконец мне нужны некоторые рекомендации о том, как организовать свой проект слоев или папок? Я вижу много способов, и я смущен о том, что выбрать или в каком формате я должен основывать свой собственный? !!

Answer 1

Вы не должны использовать свои сущности данных в более высоких слоях вашего приложения. Преобразование/составление/копирование данных из DAL в модель представления или бизнес-классы с использованием библиотеки, например Automapper. Это обеспечивает независимость слоев вашего приложения и скрывает вашу схему базы данных от конечных пользователей.

Имейте в виду, что MVC касается презентации, все реальные работы должны выполняться в других слоях вашего приложения. Я пытаюсь сохранить слои независимыми и использовать немного кода для склеивания, чтобы связать их с приложением. Я могу писать уровни доступа к данным и бизнес-логики при работе над проектом MVC, но затем повторно использовать в утилите командной строки. Существует много книг, в которых говорится о написании качественного кода. Я лично нашел Clean Code, Code Complete 2 и Design Patterns очень полезно.

Answer 2

Как сказал LeffeBrune, это плохая практика, чтобы прямо показать ваши объекты данных на уровень презентации, вы можете попытаться выявить некоторые интерфейсы в виде проектных сервисов, которые возвращают модель представления в контроллер. Это может помочь разделить слои и внедрить шаблон «Единица работы» и некоторые другие интересные вещи.

Вы можете начать читать Скотт Просо книги

ASP.NET Шаблоны

для отправной точки при проектировании хорошего слоистую приложения, here свой блог.

Answer 3

Вы можете определить интерфейсы в бизнес-слое , который могут реализовать ваши объекты EF; бизнес-логика не знает о фактической реализации. Для этого вам понадобится уровень данных для ссылки на бизнес-уровень , что означает, что вы инвертируете зависимости. Затем вы используете контейнер IoC для привязки интерфейсов к их реализациям. ... но да, это один из многих, многих способов сделать это.

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

Answer 4

Ваши вопросы требуют много дискуссий.

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

1. CSLA.NET: CSLA .NET framework - это среда разработки приложений, которая снижает затраты на создание и обслуживание приложений. Rockford Lhotka, создатель CSLA.NET, имеет несколько книг, которые глубоко описывают оптимальную инфраструктуру проекта; все ваши вопросы ответили в его книгах.
2. Microsoft Spain - Domain Oriented N-Layered .NET 4.0 Sample App: проект/образец умышленно ограничивается .NET-реализацией наиболее часто используемых шаблонов в N-Layered Domain Oriented Architecture, основанных на простых сценариях, которые легко понять (клиенты, заказы, банковские переводы и т. Д.). Проект/образец очень хорошо документирован, и все ваши вопросы также ответили в проекте.

В целом, модели просмотра, POCOs, уровни и т. Д. Представляют собой концепции, которые имеют корень в архитектуре программного обеспечения, и я считаю, что они не могут быть описаны кратко.

Answer 5

Что я обычно использую - это слой POCO для использования в моем доступе к данным и слой модели представления для использования в моих представлениях, как сказал ЛеффеБрун. Все мои слои используют POCOs, и контроллеры несут ответственность за построение модели представления, которая нужна каждому виду. Чтобы автоматизировать эту работу, я использую automapper. Так моя структура раствора становится обычно должно быть так:

• Модель (POCO)
• доступа к данным (NHibertante)
• служба (Business Layer)
• Web (UI)
  • ViewModel