Passagem de dados entre a camada de negócios e camada de acesso a dados - código ruim?

Question

Eu estou usando o seguinte código dentro da classe JCProperty para recuperar dados a partir de uma DAL:

Dim x As JCProperty
        x = JCPropertyDB.GetProperty(PropertyID)

        If Not x Is Nothing Then
            Me.PropertyID = x.PropertyID
            Me.AddressLine1 = x.AddressLine1
            Me.AddressLine2 = x.AddressLine2
            Me.AddressLine3 = x.AddressLine3
            Me.AddressCity = x.AddressCity
            Me.AddressCounty = x.AddressCounty
            Me.AddressPostcode = x.AddressPostcode
            Me.TelNo = x.TelNo
            Me.UpdatedOn = x.UpdatedOn
            Me.CreatedOn = x.CreatedOn
            Me.Description = x.Description
            Me.GUID = x.GUID
        End If

Isso funciona bem, mas exige que o objeto DAL (JCPropertyDB) está ciente do objeto de negócios (JCProperty) e eu efetivamente criar e preencher o mesmo objeto duas vezes (uma vez no DAL para retornar à BL e depois novamente dentro do BL objeto para preencher em si).

Eu estou faltando alguma coisa aqui, eu sei que deve haver uma maneira melhor!

Efetivamente eu preciso atribuir 'Me = x' que não é permitido. Alguém pode me colocar em linha reta?

Answer 1

Pessoalmente, eu sou preguiçoso. Eu costumo fazer algo como:

class JCProperty : inherits JCPropertyDB
   {

   New()
      {
      MyBase.New()

      GetProperty(PropertyID)

      }
   }

Em seguida, você está basicamente feito, até que você tenha algumas funcionalidades adicionais na classe JCProperty que precisa acontecer "em cima" da funcionalidade já existente no JCPropertyDB. Então você substituir os métodos JCPropertyDB para chamar o método base primeiro e depois adicionar o seu novo funcionalidade.

Ron

Answer 2

Você está no caminho certo no entanto falta um ponto ligeiramente.

Normalmente, o Data Access Layer (DAL) voltaria transferência Data Objects (DTO) a partir de seu banco de dados. Estes são Plain Old CLR Objects (POCO) que não contêm lógica de negócios, simplesmente propriedades mais ou menos mapeamento para as tabelas de banco de dados.

Você teria, então, de código que cria um Domínio Modelo destes DTOs, referido como um Data Mapper . As classes no modelo de domínio pode ter nomes semelhantes. (I CustomerDTO -> Cliente), mas além de os dados, eles conterão regras de validação e, possivelmente, outra lógica de negócios

É esse modelo de domínio que você usar em sua camada de negócios, não os DTOs reais. Isto significa que se você mudar os DTOs retornados do DAL (ou seja, através da implementação de uma nova ferramenta ORM), você só tem que modificar seu Data Mapper fornecendo as estadias do modelo de dados do mesmo.

Eu recomendo a olhar para padrões de arquitetura de aplicações corporativas da Martin Fowler para padrões de acesso de dados.

Answer 3

Não tenho certeza se isso vai responder a sua pergunta, mas o ponto importante é que o modelo de domínio é independente da exibição e independente de armazenamento. Isso é muitas vezes denotado como separação de interesses. A idéia é fazer com que os acoplamentos soltos e criar um sistema simples onde os objetos não têm várias responsabilidades completamente diferentes.
Então, o que eu faria, é permitir que o DAL para criar objetos de negócios diretamente, mas ter certeza que eu não contaminam os meus objetos de negócios com qualquer coisa relacionada com o DAL. Da mesma forma que eu não quero contaminá-los com coisas específicas-UI como HTML. Na minha opinião, é ok que tanto a camada de negócios, DAL e UI-layer todos têm dependências ao modelo de domínio, no entanto, não está ok para ter dependências do modelo de domínio e para esses outros componentes.
Para soltar os engates, usando algo Primavera ou qualquer outro container de injeção de dependência, juntamente com interfaces e fiação pode ajudá-lo.
Recriando o mesmo objeto em cada camada que você está violando o princípio de DRY (não repetir-se) e você está introduzindo código de placa de caldeira e aumentando a possibilidade de introdução de um algum lugar erro.

Answer 4

Confira: http://www.icemanind.com/layergen.aspx

Answer 5

Fui tomar em BOs e enviando BOs de volta a partir da DAL via o padrão de ponte e modelo de provedor. Eu não posso ver o ponto de DTOs a menos que eu estava com medo de serialização pesado (dizer um serviço web ou JSON). A minha abordagem tem sido a de abstrair a Data-Layer e camada de negócios através de uma interface e fornecer uma camada de dados anônimo alimentado no objeto de negócios. Isso significa que eu pode ligar em qualquer camada de dados, implementar uma interface que tem métodos de carga universal e Save e que depois é acessível através de minha camada de domínio. Não há nenhum código DAL no BL - simplesmente uma chamada para um de camada de dados fornecidos e abstraída. Minha chamada para a camada de dados é gerida por um padrão de provedor (nenhuma referência direta) e eu simplesmente fazer:

public class Person : IBusinessObject<Person>
{
   protected IDataLayer<T> dataLayer;

   Person Load() { this.dataLayer.Load(this); }

}

na camada de dados que tenho ...

public class PersonMapper : IDataLayer<Person> 
{
    Person Load(Person person) {
    ...get DB stuff...map to person...decorate object...
       return person;
    }
}

Eu ainda não sei se isso é bom, mas ele funciona muito bem para mim. Eu consegui obter carga lenta em, bem como para objetos aninhados usando reflexão.