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

Если у вас есть, например, таблица базы данных с именем Person (ID, Name и т. Д.), Какой тип объекта должен возвращать уровень доступа к данным на бизнес-уровень? Я думаю примерно так:

//data access tier
public class DataAccess{

   public interface IPerson{
      int ID{ get; set; }
      string Name{ get; set; }
   }

   internal class Person : IPerson{
      private int id;
      private string name;

      public int ID{ get{return id; } set{ id=value; } }
      public int Name{ get{retutn name; } set{ name=value; }
   }

   public static IPerson GetPerson(int personId)
   {
      //get person record from db, populate Person object
      return person;  
   }
}

//business tier
public class Person : IPerson{
   private int id;
   private string name;

   public int ID{ get{return id;} set{id=value;} }
   public string Name{ get{return name;} set{name=value;} }

   public void Populate(int personId){
      IPerson temp = DataAccess.GetPerson(personId);
      this.ID = temp.ID;
      this.Name = temp.Name;
   }
}

Но все это кажется немного громоздким? Есть ли более элегантное решение этой проблемы? Должен ли я вместо этого возвращать DataRow из уровня доступа к данным на бизнес-уровень?


person Matthew Dresser    schedule 05.02.2009    source источник


Ответы (4)


Вам не нужно повторять определение класса на уровне доступа к данным (DAL).

Вы можете создавать свои бизнес-объекты как «тупые» контейнеры в отдельной сборке, например ваш класс Person может быть просто: -

public class Person
{
    int ID { get; set: }
    string Name { get; set: }
}

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

В этой статье Имара Спааньяарса есть хорошее объяснение этого шаблона.

person Adam Ralph    schedule 05.02.2009
comment
Разве предоставление DAL ссылки на уровень бизнес-сущностей не приведет к [нежелательной] двусторонней зависимости? - person Matthew Dresser; 06.02.2009
comment
Нет, уровень бизнес-объектов не будет иметь ссылки на DAL. Это просто набор «тупых» контейнерных объектов. Часть вашего приложения (пользовательский интерфейс или отдельный уровень бизнес-логики), которая запрашивает их из DAL, должна находиться в другой части сборки и должна ссылаться как на DAL, так и на сущности. - person Adam Ralph; 06.02.2009
comment
Сборка A: Определение класса, ничего, кроме полей и свойств. Сборка домена. Сборка B: DAL. Ссылки на сборку A. Сборка C: UI. Ссылки на сборку A и B. - person ; 22.07.2009
comment
@ yodaj007 - правильно. Вы также можете ввести уровень бизнес-логики (BLL), такой как классы «Manager» в статьях Imar. Ваша «сборка домена» приравнивается к сборке бизнес-объектов Imar (BO). Тогда ссылки следующие: - UI- ›BO, UI-› BLL, BLL- ›BO, BLL-› DAL, DAL- ›BO. - person Adam Ralph; 24.07.2009

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

Чтобы решить вашу конкретную проблему, вы можете:

  • Создайте базовые объекты данных / сущности на уровне данных и передайте их бизнес-уровню для использования.
  • Или, как вам кажется, создайте DTO (объекты передачи данных), которые существуют исключительно как средство передачи данных из уровня данных в более широкую реализацию вашего бизнес-объекта на более высоком уровне. Вы можете сделать это как часть шаблона репозитория в расширенной модели предметной области.

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

person flesh    schedule 05.02.2009

Если вы создаете интерфейсы для своих классов DAO и размещаете их на своем бизнес-уровне, вы можете ссылаться на свой бизнес-уровень с уровня доступа к данным. Классы DAO на уровне данных возвращают объекты с бизнес-уровня.

Ваш бизнес-уровень ссылается на интерфейсы вместо прямой ссылки на объекты доступа к данным. Внедрение зависимости через контейнер IoC (например, Castle Windsor) позволит вам добиться этого.

Этот метод называется разделенным интерфейсом и описан здесь:

http://www.martinfowler.com/eaaCatalog/separatedInterface.html

Лучшее объяснение этой техники, которое я видел, можно найти в этой статье Билли Маккафферти о лучших практиках NHibernate.

http://www.codeproject.com/KB/architecture/NHibernateBestPractices.aspx

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

person Jim Petkus    schedule 06.02.2009

Поскольку это правило, что каждый уровень должен быть слабо связан с верхним уровнем, добавление ссылки BL к DAL не является хорошей идеей. Лучше определить модель данных в DAL с помощью интерфейса и создать бизнес-форму в BL. По моему опыту, лучше использовать репозиторий в DAL и доступ к нему в вашей бизнес-сущности или бизнес-процессе.

person Ehsan    schedule 07.05.2013