Entity Framework в многоуровневой архитектуре

Question

Я использую многоуровневую архитектуру с Entity Framework. Вот что я придумал до сих пор (все проекты, кроме UI, являются библиотекой классов):

• Объекты : Объекты POCO. Полностью настойчивость невежественна. Нет ссылки на другие проекты. Сгенерировано Microsoft ADO.Net POCO Entity Generator.

• DAL : файл EDMX (Entity Model) с классом контекста. (генерируется t4). Рекомендации: Entities

• BLL : уровень бизнес-логики. Реализует шаблон хранилища на этом слое. Рекомендации: Entities, DAL. Вот где объектконтекст заполняется: var ctx=new DAL.MyDBEntities();

• UI : Уровень представления: веб-сайт ASP.NET. Ссылки: Entities, BLL + запись строки подключения к сущностям в файле конфигурации (вопрос № 2).

Теперь мои три вопроса:

1. Правильный ли подход к определению слоя?

2. В моем пользовательском интерфейсе я получаю доступ к BLL следующим образом:
   var customerRep = new BLL.CustomerRepository();<br> var Customer = customerRep.GetByID(myCustomerID);

   Проблема в том, что мне нужно определить строку подключения к сущностям в моем пользовательском интерфейсе web.config / app.config, в противном случае я получаю исключение времени выполнения. Разве определение строки соединения сущностей в пользовательском интерфейсе портит различие уровней? Или это приемлемо в многоуровневой архитектуре.

3. Должен ли я предпринять какие-либо дополнительные шаги для отслеживания чейджа, отложенной загрузки и т. Д. (Под т. Д. Я имею в виду функции, которые Entity Framework включает в обычный, 1 проект, не генерирующий код POCO)?

Спасибо и извинения за длинный вопрос.

Answer 1

BLL: уровень бизнес-логики. Реализует шаблон хранилища на этом слое

Я не совсем согласен с этим. Репозиторий предназначен для абстрагирования основного хранилища данных (SQL Server, XML и т. Д.). Это проблема уровня данных, а не бизнес - поэтому, почему это должно быть в BLL?

Правильно ли подходит мой подход к определению слоев?

Вид. :) Это немного субъективно, но обычно у вас есть:

• Данные
  • Хранилище идет сюда.
• Бизнес
  • Бизнес-правила, логика домена и сущности.
• Презентация
  • Пользовательский интерфейс / веб-приложение.

Теперь обычно эти три разбиваются дальше. Так что в вашем случае я бы имел:

1. MyCompany.MyProject.Data (Репозиторий)
2. MyCompany.MyProject.Business.Services (вызывает хранилище, применяет бизнес-правила и т. Д.)
3. MyCompany.MyProject.Business.DomainModel (Entities)
4. MyCompany.MyProject.UI (веб-приложение)

Должен ли я предпринять какие-либо дополнительные шаги для отслеживания чейджа, отложенной загрузки и т. Д. (Под т. Д. Я имею в виду функции, которые Entity Framework включает в обычный, 1 проект, не генерирующий код POCO)?

Если вы не используете POCO (например, вы используете генерацию кода по умолчанию). Тогда вам не нужно беспокоиться об отслеживании изменений.

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

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

Если вы используете приложение ASP.NET MVC, если у вас отложенная загрузка, ваш View может в конечном итоге вызвать базу данных во время рендеринга, нарушая шаблон MVC.

Answer 2

Проблема в том, что я должен определить Строка подключения сущностей в моем Пользовательский интерфейс web.config / app.config в противном случае я получить исключение во время выполнения.

Строка подключения всегда берется из app.config / web.config исполняемого домена приложения (здесь ваше приложение asp.net, а не DAL). Поэтому вы можете создать XML-файл для хранения настроек в своем проекте DAL и прочитать эти настройки, используя классы XML, предоставляемые dot net framework

Answer 3

1) Слои мне кажутся нормальными

2) Не вижу проблемы со строкой соединения в вашем пользовательском интерфейсе app.config. Должен быть определен где-то. Вы можете скопировать свой DAL.config в папку BIN вашего приложения, в которой, вероятно, была создана строка подключения, когда вы создавали проект, но мне это не показалось бы правильным. Я бы лично управлял этим на вашем уровне пользовательского интерфейса app.config