Многоуровневая архитектура в Entity Framework 4.0

Question

Привет Я стараюсь архитектор небольшой проект. Я планирую использовать Data acess, Business Service, WcfService, UI Layer.

Я пытаюсь использовать EF 4.0 и MVC 2.0. Мой вопрос в том, где сгенерировать сущности и ObjectContext через EF. Я изначально планировал его в DataAccess. но чтобы сделать сущности доступными во всем слое, я должен ссылаться на dll DataAccess на всех уровнях (что не является хорошим подходом).

Могу ли я создать объекты в новом слое Entities и оставить ObjectContext в DA. Как хорошо это работает.

Основные различия между сущностями и POCO? (оба должны генерироваться EF).

Являются ли эти объекты доступными как DataContract (Seralized) по умолчанию?

Я стараюсь избегать повторения кода как можно больше. дайте мне знать, как это будет работать.

Благодаря

Answer 1

Эй Недавно я взглянул на статью this. Это то, что я искал. POCO не может использоваться в сценарии WCF. Лучше всего использовать объекты Self tracking, и для этого мы можем использовать шаблоны t4 для генерации кода. Я не отвечаю на мой вопрос, это будут объекты самообучения.

Преимущество использования STE объясняется в статье this четко.

Answer 2

Я бы рекомендовал принимать взглянуть на «реальном мире» пример приложения под названием NerdDinner и 185-страничный PDF пошаговое руководство «как-каждая линия-была написана» на Code Plex.

Запуск приложения здесь: http://www.nerddinner.com/

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

Answer 3

Бизнес-логика должна быть четко отделена от доступа к данным; как вы правильно сказали, плохое распространение общих объектов между всеми уровнями доступа к данным.

• Используйте свой ПОКО, чтобы передавать данные между слоями, определить их в общем собрании, который очень свободен от зависимостей (потому что все проекты, которые должны обмениваться данными нужно будет ссылаться на него.
• отделить бизнес-логику и данных Доступ с помощью интерфейса, интерфейс будет определять методы, которые вызываются для передачи и ввода данных - и эти данные будут передаваться либо в качестве базового базового типа (int, string, bool и т. Д.), Либо в POCO (определенный в вашей общей сборка)
• В ваших данных Доступ к импиментации использует то, что вы хотите - что в вашем случае EF. Это означает, что вам нужно будет преобразовать объекты EF в POCOs, но это означает, что ваша архитектура чистый.

Но как бы я создаю ПОКО (в коде поколения), а как лица?

Я работаю с точки зрения, что бизнес-логика - это то, где вещи «начинают» концептуально; сказать, что он воплощает модель домена, также будет довольно точным.

POCO - это то, как мы передаем информацию вокруг - и по большей части их дизайн будет определяться потребностями бизнес-логики (или модели домена). В случае использования модели домена/DDD POCO может быть частью этого домена (на данный момент я все еще не уверен, что это проблема или нет).

Итак - как они генерируются (концептуально) в соответствии с потребностями бизнес-логики; однако, если производительность является ключевым аспектом ваших требований, у вас также могут быть некоторые из них, связанные с проблемами, связанными с производительностью (например, получение большого количества данных обратно в один большой DTO, а не во многих более дискретных вызовах).

Как они создаются физически? Ну, я пишу их либо вручную, либо используя небольшой инструмент, который я взломал. Я предпочитаю использовать Structs (и Collections) для моих POCO, но вместо этого вы можете использовать classes.

Я не смотрел в создании авто-магически от бизнес-логики или домена модели в течение нескольких причин:

• Это трудно.
• После создания они не имеют тенденций сильно меняться - и вы не хотите, чтобы они использовались всеми вашими сборками, вы быстро сломали бы всю вашу систему.
• Я создаю разные POCO по разным причинам, и это определенно суждение человека.