уровень доступа к данным - модульность и возможность повторного использования

Question

Я действительно новичок в этом и пытаюсь найти лучшую для меня архитектуру уровня доступа к данным.У меня есть 3 уровня в моем решении:

1. Уровень представления - приложение ASP.net
2. Уровень бизнес-логики - объекты и логика c #
3. Уровень доступа к данным - функции, которыевызов хранимых процедур.

Я хочу заменить слой доступа к данным.

В случае, если я, например, использую Entity Framework или NHibernate, это гарантирует, что позже я смогу заменить этот доступ к даннымуровень без внесения изменений в уровень бизнес-логики?
Где происходит использование интерфейсов в Entity Framework или NHibernate?

Answer 1

Разработайте интерфейс, который отображает все ключевые методы, которые вы бы использовали в своем DAL. Тогда только ссылаться на классы DAL через интерфейс. Это придаст ему модульность, отделив слои друг от друга.

Всякий раз, когда вам нужно поменять указанный DAL, вам просто нужно вставить новый DAL, который реализует указанный интерфейс. Остальная часть вашего кода не будет мудрой для изменения.

Только один подход к вашей проблеме.

Answer 2

В частности, nHibernate (3.0+) и EF поддерживают LINQ, поэтому вы создаете простой интерфейс IRepository, который принимает Expression<Func<TItemType,bool>>, и избегаете использования репозиториев, имеющих GetPersonByID, getPersonByName и т. Д. Хотя это может помешать вам обменять ORM Iподумайте, что вы не будете использовать ORM, который не поддерживает LINQ.

Этот интерфейс может выглядеть примерно так (это НЕ полная реализация! Это просто демонстрация, и реальный интерфейс нуждается в лучшей доработке! Это просто то, что я сейчас смоделировал! Возможно, потребуется также реализовать IDisposable и т. Д.):

interface IRepository<TPersistant>
{
      void Save(TPersistant item);
      void Delete(TPersistant item);

      TPersistant Find(Expression<Func<TPersistant,bool>> predicate); 
      // maybe findOne or findMany

      // maybe something like this
      IQueryable<TPersistant> Query();
      /* Other stuff like updating, transactions, commiting, etc.*/
}

Я бы,однако, хотел бы упомянуть некоторые вещи, которые люди игнорируют при абстрагировании DAL. Это моё мнение - все мое мнение .

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

Когда вы полностью абстрагируете DAL, вы можете потерять другие специфические функции ORM, которые фактически делают егоORM лучше других или даже будущих оптимизаций производительности ради абстракций.i / e Будущие запросы в nHibernate (которые являются огромной функцией), которые вы в основном теряете, если абстрагируете их.Вы также можете потерять ленивую оптимизацию инициализации (выберите проблемы N + 1), поскольку вы не можете использовать Fetch (nHibernate) или Include (EF).Даже такие мелочи, как поддержка enum (я считаю, что EF STILL не поддерживает).

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

Так что пока я не говорю, не абстрагируйся от DAL, потому что есть много преимуществ, таких как модульное тестирование, развязка и т. д. (хотя вы всегда можете создать репозиторий «связанный с dal», который помог бы с модульным тестированием), это то, что должно (), если стоит заплатить цену некоторых функций, которые фактически делают nhibernate / EFлучше, чем другие.

Answer 3

Чтобы сохранить бизнес-уровень, вы также должны сохранить модель.Потому что у бизнеса очень тесная связь с моделью.

То, что вы можете изменить, это слой, который отображает вашу модель в базу данных.

И NHibernate, и Entity Framework 4.1 допускают то, что мы называем объектами POCO.Объекты POCO - это чистые объекты CLR, которые не ссылаются на какие-либо персистентные классы.То есть: он не содержит никаких атрибутов, базовых классов или вызовов методов, которые бы связывали этот класс со сборкой.При использовании NHibernate вы можете сопоставить эти классы POCO с базой данных, используя файлы XML или свободно методологию, используя Fluent NHibernate.В EF4.1 вы можете использовать только свободную методологию.

Одна вещь, о которой вы должны беспокоиться - это использование stored procedures.Это то, что по своей природе компрометирует замещение персистентного слоя.EF4.1 Подход POCO в настоящее время не поддерживает хранимые процедуры.NHibernate, вероятно, делает, но я не уверен.

РЕДАКТИРОВАТЬ

Как упоминал Мэтью Кокс.Конечно, для классов DAL понадобятся интерфейсы.Потому что операции CRUD будут различаться в зависимости от уровня сохраняемости.Эти интерфейсы позволяют заменять постоянство.

Пример:

public class IPersonDAL {
    IList<Person> GetPeople();
    void InsertPerson(Person person);
    ...
}