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

Question

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

//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;
   }
}

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

Answer 1

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

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

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

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

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

Answer 2

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

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

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

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

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 с интерфейсом и создать форму бизнес-объекта в BL.по моему опыту, лучше использовать репозиторий в DAL и access в вашем бизнес-объекте или бизнес-процессе.