Это двойная работа, создавая компонент доступа к данным и бизнес-компонент?

Question

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

Мои бизнес-компоненты (например, business.components.usercomponent) в настоящее время имеет следующий метод:

public void Create(User entity)
{
    using (DataContext ctx = new DataContext())
    {
        ctx.Users.AddObject(entity);
        ctx.SaveChanges();
    }
}

Мне нравится этот дизайн. Однако я столкнулся с некоторыми примерами в Интернете, которые будут рекомендовать следующую реализацию:

public void Create(User entity)
{
    // Instanciate the User Data Access Component
    UserDAC dac = new UserDAC();
    dac.InsertUser(entity);
}

Это приведет к созданию компонента доступа к данным для всех объектов, каждый из которых содержит основные методы (создание, редактирование, удаление ... и т. Д.).

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

Что будет считаться наилучшей практикой для правильной реализации основных функций Crud в слоистом приложении? Если они будут «закодированы» в бизнес-компонентах или в компоненте доступа к данным?

Answer 1

Это зависит. Если вы ожидаете, что ваш бизнес-уровень просто выполняет операции CRUD, чем вы можете следовать вашему первоначальному подходу. Если вы планируете использовать большую бизнес-логику, где бизнес-компонент будет работать со многими объектами второго подхода, лучше.

Причина, почему люди любят использовать второй подход, - это тестирование и постоянство невежества. Если вы используете первый подход, ваш бизнес-компонент плотно связан с основой. Mocking ObjectContext не очень простая задача, поэтому тестирование сложно. Если вы используете второй подход, ваш бизнес-уровень не зависит от постоянного слоя. Вы можете легко проверить его, и вы даже можете изменить уровень постоянства, если вам нужно. Но это более продвинутые концепции, которые вы, вероятно, не ищете в данный момент. Ваш код понадобится для реализации дополнительного улучшения.

ЦАП может быть также реализован в качестве репозитория. Есть много способов создавать универсальный репозиторий, чтобы у вас был только один класс, и вы определяете тип сущности при репозитории Instance:

var repository = new GenericRepository<User>();

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

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