Является ли двойной работой создание компонента доступа к данным и бизнес-компонента? - PullRequest
Новая
       32

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

1 голос
/ 03 сентября 2010

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

Мои бизнес-компоненты (например, 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 в многоуровневом приложении? Должны ли они быть «закодированы» в бизнес-компоненте или в компоненте доступа к данным?

1 Ответ

1 голос
/ 03 сентября 2010

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

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

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

var repository = new GenericRepository<User>();

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

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

...