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

Question

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

//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 из уровня доступа к данным на бизнес-уровень?

Answer 1

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

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

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

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

Эта статья Imar Spaanjaars содержит хорошее объяснение этого паттерна.

Answer 2

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

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

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

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

Answer 3

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

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

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

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

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

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

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

Answer 4

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