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

Question

Привет Я пытаюсь архитектор небольшой проект. Я планировал иметь доступ к данным, 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

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

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

Но как бы я создал POCO (при генерации кода) каккак сущности?

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

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

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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