Разделение Касается Repository Pattern & Entity Framework 3.5

Question

Я пытаюсь быть лучшим разработчиком ...

Что я работаю с:

1. .Net MVC Framework 1.0
2. Entity Framework 3,5

Я делал некоторое чтение, и я думаю, что я хочу сделать, это:

1. Создайте репозиторий для каждого агрегата в домене. Например, хранилище заказов будет управлять OrderItems заказа.
2. Создайте сервисный уровень для обработки бизнес-логики. Каждый репозиторий будет иметь соответствующий объект службы с аналогичными методами.
3. Создать DTO в прошлом между хранилищем и сервисом
4. Возможно создание ViewModels, которые являются классами для View, чтобы потреблять.

У меня есть интерфейс хранилища базы, который мои агрегатные интерфейсы хранилища будет осуществлять ...

public interface IRepository<T> 
    { 
     IEnumerable<T> ListAll(); 
     T GetById(int id); 
     bool Add(T entity); 
     bool Remove(T entity); 
    } 

Мой заказ Repository интерфейса определяется следующим образом ..., вероятно, будет использовать дополнительные методы, как я получить больше в это упражнение.

public interface IOrderRepository : IRepository<Order> 
{ 
} 

Мои классы обслуживания по существу определяются так же, как и репозитории, за исключением того, что каждая реализация службы включает в себя бизнес-логику. Сервисы будут использовать интерфейс репозитория в конструкторе (я не готов к IoC в этом упражнении, но считаю, что именно там я хотел бы закончить вниз по дороге).

1. Реализация хранилища будет выталкивать и извлекать из базы данных с помощью Entity Framework. При получении данных; методы возвратят только DTO, а не созданные EF объекты.
2. Службы (как я их называю) будут управлять репозиторием и выполнять бизнес-логику. Услуги - это то, что вы увидите в контроллере, то есть _orderService.GetById (1).
3. Здесь я начал flip flopping и мог использовать некоторую обратную связь ... Должен ли я, если бы мои классы обслуживания заполняли классы ViewModel ... не следует ли иметь классы ViewModel .... возможно, это слишком много картирование от одного типа другому?

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

Благодаря

Answer 1

Я думаю, что вы движетесь в правильном направлении вокруг Repository рисунка. Что касается вашего вопроса о классах ViewModel, я предлагаю вам использовать что-то, что преобразует вывод выходных данных метода бизнес-сервиса на некоторые требуемые выходы. Например, бизнес-сервис вашего заказа может иметь метод, называемый GetOrders(). Используя настраиваемый атрибут, вы можете определить для него тип класса представления. Представление может получить результат этого метода, возможно, присоединяется к нему с другими видами данных и возвращает результат как совокупность объектов с анонимными типами.В этом случае представление примет IQueryable<Order> или IEnumerable<Order> как входной сигнал и возвращает IList в качестве выхода.

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