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

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

Ответ 1

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

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

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

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

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

Ответ 2

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

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

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

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

Ответ 3

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

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

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

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

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

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

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

Ответ 4

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