2012-06-29 3 views
5

Попытка реализовать трехслойный (не: уровень, я просто хочу отделить мой проект логически, на одной машине). Архитектура. Я нашел так много разных подходов, которые меня путают , что лучший способ (если есть), чтобы сделать это в приложении WinForms.3-х слойная архитектура - передача данных между слоями

Теперь у меня нет никаких сомнений, только около 3 слоев, которые должны присутствовать в проекте:

  • UI (Presentation Layer)
  • BLL (Business Logic Layer)
  • ВВЛ (Data Acces Layer)

UI Я положил все WinForms. Должна быть также некоторая логика, чтобы заполнить объект данными из элементов управления и передать его на уровень BLL.

В DAL Я хочу поставить классы и методы для манипуляций с данными с помощью ADO.NET, как:

public class OrderDAL 
{ 
    public OrderDAL() 
    { 
    } 

    public int Add(Order order) 
    { 
     //...add order to database 
    } 

    public int Update(Order order) 
    { 
     //...update order in database 
    } 

    //...etc. 
} 

Проблема с BLL и вопрос - я должен использовать Передача данных объектов в передавать данные между слоями, или я должен пройти весь класс?

Если я выбираю использовать DTO, то я имею создать дополнительный общий класс, Order, что ссылка на UI, BLL и DAL:

public class Order 
{ 
    public int Id { get; set; } 
    public DateTime Date { get; set; } 
    public string Number { get; set; } 
    public string CustomerName { get; set; } 

    public Order() 
    { 
    } 
} 

и поставить логику отделенный в УСК :

public class OrderBLL 
{ 
    public OrderBLL() 
    { 
    } 

    public int Add(Order order) 
    { 
     OrderDAL orderDAL = new OrderDAL(); 
     return orderDAL.Add(order); 
    } 

    public int Update(Order order) 
    { 
     OrderDAL orderDAL = new OrderDAL(); 
     return orderDAL.Update(order); 
    } 

    //...etc. 
} 

Этот подход, под разными названиями, используется, помимо прочего: here или here.
С другой стороны, некоторые «мудрые парни» и их последователи (например, here) называют это Anemic Domain Model и жалуются, что это плохой дизайн и анти-шаблон, который не следует использовать.

Плюсы:

  • DTO может легко дизайн для представления таблицы базы данных,
  • это свет и ясно, содержит только поля, необходимые для базы данных,
  • DAL не должен ссылаться BLL,

Минусы:

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

Таким образом, противоположный подход передать весь объект между слоями, как here: нет DTO, просто BLL не похожий, что:

public class Order 
{ 
    public int Id { get; set; } 
    public DateTime Date { get; set; } 
    public string Number { get; set; } 
    public string CustomerName { get; set; } 

    public Order() 
    { 
    } 

    public int Add() 
    { 
     OrderDAL orderDAL = new OrderDAL(); 
     return orderDAL.Add(this); 
    } 

    public int Update(Order order) 
    { 
     OrderDAL orderDAL = new OrderDAL(); 
     return orderDAL.Update(order); 
    } 
} 

Плюсы:

  • это красиво инкапсулированный объект, следуя правилам ООП (я полагаю;)).
  • как логика, так и свойства находятся в одном месте, легче поддерживать и отлаживать.

Минусы:

  • использовать объект, DAL должен ссылаться на BLL (это не так, как 3-х уровневая слой должен делать, не так ли?).
  • класс может содержать некоторые поля, которые не используются в базе данных, а также некоторые поля из базы данных (например, Id) не представляют собой объект «реальной жизни».

Итак, похоже, что бы я ни выбрал, я нарушу некоторые правила. Что лучше, тогда я должен выбрать? Может быть, есть другой подход, которого я не нашел?

+0

Я предлагаю вам ознакомиться с http://en.wikipedia.org/wiki/Domain-driven_design – HatSoft

ответ

7

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

Мне также не нравится идея создания объектов модели, ответственных за их собственную постоянство. Я предпочитаю отдельный слой сохранения. Зачем? Объекты модели не всегда должны сохраняться, чтобы быть полезными. Бизнес-логика и функциональность являются ортогональными для сохранения.

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

Мой совет? Не делайте DTO. Разбейте отдельный слой сохранения.

Смежные вопросы