Que objetos devem retornar da camada de acesso a dados para a camada de negócios um sistema n-tier

Question

Se você tiver, por exemplo, uma tabela de banco de dados chamado Pessoa (ID, nome etc) que tipo de objeto deve o acesso a dados níveis de retorno para a camada de negócios? Estou pensando em algo parecido com isto:

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

Mas tudo isso parece um pouco complicado? Existe uma solução mais elegante para este problema? Devo retornar um DataRow da camada de acesso a dados para a camada de negócios em vez disso?

Answer 1

Você não precisa repetir a definição de classe em sua camada de acesso a dados (DAL).

Você pode criar suas entidades empresariais como recipientes 'mudos' em um assembly separado, por exemplo, sua classe Pessoa pode ser apenas: -

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

Em seguida, você pode dar o seu DAL uma referência à camada de entidades empresariais. Seus objetos de controlador, se eles estão em uma camada de lógica de negócios separada, ou dentro de sua camada de interface do usuário, pode, então, basta ligar para o DAL, que pode criar uma entidade empresarial, preenchê-lo do banco de dados e devolvê-lo ao seu controlador.

Este artigo por Imar Spaanjaars tem uma boa explicação para esse padrão.

Answer 2

A sua camada de negócios definitivamente não quer saber sobre as linhas de dados - para tentar classes específicas de dados licença na camada de dados. Isso reduz o acoplamento e liberta-o para mudar a sua camada de persistência em uma data posterior, sem atacado re-arquitetura.

Para resolver o seu problema específico, você pode:

• Criar dados objetos / entidades básicas em sua camada de dados e entregá-las à sua camada de negócios para o consumo.
• Ou, como parece que você está fazendo, criar DTOs (Transferência de Dados Objects) que existem apenas como um meio de transferência de dados a partir da camada de dados para uma implementação mais rica de seu objeto de negócios em uma camada superior. Você pode fazer isso como parte de um padrão de repositório em um modelo de domínio rico.

A outra coisa que você pode querer pensar é tiers v camadas - ele faz a diferença como você pensa sobre essas coisas. Tiers são geralmente físico, em outras palavras, eles definem as fronteiras entre processos. Camadas são geralmente lógico, eles se separam funcionalidade de um programa em unidades de baixo acoplamento. Você está apontando para camadas neste caso.

Answer 3

Se você criar interfaces para as classes DAO e colocá-los dentro de sua camada de negócios, você pode fazer referência a sua camada de negócios da camada de acesso a dados. As classes DAO no retorno camada de dados objetos da camada de negócios.

As suas referências camada de negócios as interfaces em vez de referenciar diretamente os objetos de acesso a dados. injeção de dependência através de um contêiner IoC (como o Castelo de Windsor, por exemplo) permitirá que você para fazer isso.

Esta técnica é chamada separado interface e é descrito aqui:

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

A melhor explicação desta técnica que tenho visto pode ser encontrada neste artigo sobre NHibernate melhores práticas, escrito por Billy McCafferty.

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

O artigo tem um monte de informações que são específicas para NHiberbate, mas uma boa metade do que é apenas informação sólida sobre a criação de aplicativos para ser acoplado livremente e facilmente unidade testada.

Answer 4

Como esta regra de que cada camada tem que fracamente acoplado a camada superior, acrescentando BL referência a DAL não é boa ideia. Sua melhor definir modelo de dados em DAL com uma interface e fazer formulário Entidade de Negócios no BL. como minhas experiências, o seu melhor usando Repository na DAL e acesso em em seu negócio Entidade ou Business Process.