Confusão entre DTOs (linq2sql) e objetos de classe!

Question

i têm trabalhado com sucesso com linq2sql e os DTOs LINQ (as classes que são criados por linq2sql) ....

Estou confuso, eu tenho a tarefa de atualizar um aplicativo antigo e eu posso ver que meus DTOs será usado como devem ser .... a data de transporte

Eu estou usando o padrão de repositório assim que eu estou passando dados do repositório para o serviço através dos dtos Linq2Sql ... uma vez que eu estou na camada de serviço (esta é basicamente a minha lógica de negócios), então eu preciso passar em torno de objetos de classe ..

essas classe objetos são basicamente uma imagem de espelho (mais ou menos) dos dtos - há algumas mudanças em um lugar, mas em geral o mesmo ..

Então, voltando à pergunta na mão! - isso é uma boa prática para dtos uso apenas para transportar dados a partir do repositório para a camada de serviço ... e uma vez na camada de serviço (lógica de negócio) Eu deveria, mas MAPEAMENTO todos os meus dtos para lá objeto classe partes contrárias (de curso usando AutoMapper! !)

A minha outra alternativa é continuar a usar o DTOS como objetos de classe e passá-las em torno de método para método e como tipos de retorno, etc, mas eu sinto que esta é uma prática ruim e eu continuo andando em círculos perguntando qual método devo aplicar?

Qualquer ajuda muito apreciado

graças

Answer 1

Aqui está minha opinião: Ao lidar com qualquer aplicativo não-trivial. Usando o seu LINQ2SQL objetos como seu modelo de domínio é uma péssima idéia. Vejo LINQ2SQL como um ORM e nada mais. Bases de dados (que LINQ2SQL tem uma correspondência direta com) é uma normalização das dados . Classes (no sentido OOAD) são uma normalização de comportamento (não dados).

[estes classe objetos são basicamente uma imagem de espelho] ...

Eu encontrei este ao criar aplicativos com LINQ2SQL. Vamos ser realistas .... mais linha de aplicativos de negócios são glorificados aplicações CRUD. Portanto, não é fora de questão que uma grande percentagem de entidades de sua aplicação irá corresponder diretamente às tabelas de banco de dados. Eu não queria estar vinculado diretamente ao DTO de que foram gerados, mas ao mesmo tempo eu não queria aulas duplicados espalhados em toda a minha aplicação.

Então aqui está a minha solução:
I "programado para uma interface".

Vamos dizer que tem uma PersonDto (Dto pé para objecto de Transferência de Dados) com propriedades de FirstName, LastName, Age (que se relacionam directamente com as colunas do banco de dados).

Eu criei uma interface IPerson e tive meu PersonDTO implementá-lo.

  [Table(Name="Persons")]
  internal class PersonDto : IPerson
  {
      ....
  }

E o meu método repositório iria tomar e recuperar IPerson em oposição à classe Linq2Sql.

    IPerson somePerson = _repository.Get(someGuid);
    somePerson.FirstName = "SomeName";
    _repository.Save(somePerson);

Esta abordagem tem funcionado muito bem para mim. Sempre que eu sinto que eu preciso para se desviar do DTO, posso fazê-lo com bastante facilidade por causa da interface de representar o meu objeto em oposição ao DTO.

Algumas indicações gerais: Construa a sua DTO à mão ... Eu sei que parece loucura, mas você vai descobrir que ele funciona muito bem com uma abordagem de desenvolvimento de cima para baixo, teste conduzido. (LINQ2SQL) objetos do seu DTO será extremamente leve e estará aberto a mudanças fora do designer .dbml.

Mantenha interna do DTO e DataContext do. Não há nenhuma razão para o seu dto é para ser exposto publicamente (dado que você tem interfaces públicas para você repositórios e objetos de domínio). Fazendo isso vai forçar uma separação lógica entre o seu modelo de domínio e acesso a dados.

Coloque toda a sua camada de acesso a dados em um projeto separado (novamente para impor esta separação).

Coloque suas declarações de interface em um projeto separado (isso irá garantir que você não correr em quaisquer referências circulares).

Espero que isso ajude ...

Answer 2

Na verdade, eu tinha uma pergunta semelhante sobre este tema, embora a minha intenção era ligeiramente diferente. A recomendação era usar as classes LINQ2SQL como os objetos de domínio e tirar proveito de classes parciais como os outros. A minha principal preocupação veio com a forma desses objetos (ou seja, nomes de propriedades), e da acessibilidade dos membros de classe (ie V.S. privada protegida por exemplo).

A forma dos objetos e até mesmo a acessibilidade pode ser abordado usando modelos T4, onde Damien Guard montou um modelo de T4 para lhe permitir controlar a forma das classes que Linq2Sql geraria para você. Isto pode ser visto aqui T4 modelo para Linq2SQL .

Esta é a abordagem que eu vou olhar para dentro e ver se ele aborda as minhas preocupações. Além disso, se a sua camada de serviço pode aceitar interfaces para argumentos de método você também pode controlar o que a camada de serviço tem acesso a através de wrappers de interface em torno de sua Linq2SQL DTOs.

Espero que isso ajude.

Answer 3

Esta é uma das melhores discussões sobre o tema que eu já vi:

http://blog.wekeroad.com/ blog / LinqToSql-mãe-disse-bate-você-out /

No final, o acoplamento e as decisões de coesão são situacionais e você tem que decidir o que é melhor para sua situação.

Quando o aplicativo supera LinqToSql, quão fácil vai ser para arrancar LinqToSql e inserir outro ORM em seu lugar? Isso é algo que você tem que pensar seriamente.

Em geral, minimizar o conhecimento de sua camada de negócios tem cerca de LinqToSql. LinqToSql deve ser completamente escondido de sua camada de interface do usuário (sua camada de negócios torna-se um bom pedaço deste escudo). É muito fácil de percorrer o caminho architectual errado com LinqToSql e pode ser muito difícil obter de volta no caminho certo após o fato.

Answer 4

As classes geradas pelo designer linq2sql são classes parciais, para que possa estender estes e colocar sua lógica de negócio diretamente neles. A ideia é que o LINQ é usado para persistir / reconstruir essas entidades para que você possa evitar o tipo de mapeamento que você está falando.