Entity Framework та розділення шарів

Я намагаюся трохи попрацювати з Entity Framework, і у мене виникло питання щодо поділу шарів.

Я зазвичай використовую підхід UI -> BLL -> DAL, і мені цікаво, як тут використовувати EF.

Мій DAL зазвичай був чимось на кшталт

GetPerson(id)
{
    // some sql
    return new Person(...)
}

BLL:

GetPerson(id)
{
    Return personDL.GetPerson(id)
}

Інтерфейс користувача:

Person p = personBL.GetPerson(id)

Моє запитання зараз: оскільки EF створює мою модель та DAL, це гарна ідея загортати EF всередину власного DAL або це лише марна трата часу?

Якщо мені не потрібно загортати EF, чи все-таки я розміщую Model.esmx всередині власної бібліотеки класів чи було б добре просто помістити його всередині мого BLL і попрацювати там?

Я не можу реально бачити причину загортати EF всередину власної DAL, але я хочу знати, що роблять інші люди.

Отже, замість того, щоб сказати вище, я би не залишив DAL і просто зробив:

BLL:

GetPerson(id)
{
    using (TestEntities context = new TestEntities())
    {
            var result = from p in context.Persons.Where(p => p.Id = id)            
                    select p;
    }
}

Що робити?

Приклад, який ви надаєте, навряд чи є багатошаровою архітектурою. Я знаю, що це навмисно спрощено, але:

Ваш презентаційний шар безпосередньо пов'язаний з особою Особи. Це нормально лише в найпростіших випадках, і точно не тоді, коли ви намагаєтеся визначити свої шари.

Метод GetPerson також використовує досить погану практику створення нового контексту для кожного дзвінка. Ви повинні отримати контекст у конструкторі, і він буде наданий вашим IOC-контейнером.

Проста, але ефективна структура, яку я використав:

• Project.Core - містить переглянуті моделі та інтерфейси.
• Project.DAL - з моїм EDMX та згенерованим кодом.
• Project.BLL - бізнес-логіка.
• Project.Web - сам веб-додаток.

Важливо зазначити, що:

• Ядро не залежить від будь-якого іншого рішення.
• DAL не залежить від будь-якого іншого рішення.
• Project.Web залежить від Core, але не від DAL і BLL.
• BLL залежить від Core та DAL.

Вам не потрібно нічого обертати EDMX.

Якщо ви можете передбачити можливість переходу з EF на якийсь інший підхід, можливо, ви захочете розширити свої бізнес-об'єкти (скориставшись частковими класами), щоб реалізувати інтерфейси, визначені в окремому шарі бізнес-об’єктів.

Тоді з вашого коду ви матимете справу лише з тими інтерфейсами, а не з конкретними згенерованими класами. Для скріплення цього може знадобитися невеликий код клею; що з EDMX може бути вашим DAL.

Існує два загальні підходи до шарування: суворий шарувати і розслаблений шар.

Суворошаровий підхід обмежує компоненти в одному шарі взаємодіяти лише з однолітками та з шаром безпосередньо внизу.

Розслаблений шаруватий додаток послаблює такі обмеження, що компонент може взаємодіяти з компонентами з будь-якого нижнього шару.

Використання розслабленого шару може підвищити ефективність, оскільки системі не потрібно пересилати прості дзвінки з одного шару на інший. З іншого боку, використання розслабленого шару не забезпечує однаковий рівень ізоляції між шарами та ускладнює заміну нижнього шару, не впливаючи на більш високі шари.

Для великих рішень із залученням багатьох програмних компонентів прийнято мати велику кількість компонентів на одному рівні абстракції, які не є згуртованими. У цьому випадку кожен шар може бути додатково розбитий на одну або кілька згуртованих підсистем. Малюнок 2 ілюструє можливі позначення мови уніфікованої мови моделювання (UML) для представлення шарів, що складаються з декількох підсистем.

висновок: якщо вам не потрібен середній шар, втрачайте його; не всі програми вимагають однакового підходу, і якимось чином додавання шару лише для шару призначення призведе до штрафу за складність витрат та обслуговування.