Should POCOs ser derivado de DTOs ou melhor não?

Question

Ao criar uma solução de n-tier, eu não quero expor meus objetos de negócios, mas usar DTO é em vez disso. Por outro lado, eu não quero definir duplamente objetos e escrever a cópia do código todo o tempo.

Agora, a minha idéia seria a de DTOs gravação que contêm todos os campos necessários e propriedades, mas nenhuma lógica (único estado).

Então eu iria derivar meus objetos de negócios a partir desses DTOs, estendendo-los com a minha lógica de negócios, trabalhando nas DTO propriedades classes base. Estes objectos também seriam os objectos persistiu no ORM utilizado (NHibernate).

Com essa abordagem, no lado do servidor que eu poderia trabalhar nos objetos de negócios e passá-los diretamente para o cliente (eles são derivados, assim abaixo-refratário). Eu não seria forçado a expor a minha lógica de negócios que maneira e guardar um monte de código.

Você acha que essa abordagem é sensato?

Saudações,

Sebastian

Answer 1

Você pode querer considerar o seguinte:

" ..., porque mantendo o DTO desconhece a objetos de domínio permite a reutilização o DTO em diferentes contextos. Da mesma forma, você não quer que o domínio objetos de saber sobre o DTO porque que pode significar que alterar o DTO exigiria alterar o código no lógica de domínio , o que levaria a um pesadelo de manutenção.

A melhor solução é usar o padrão Assembler , o que cria DTOs de objetos de negócios e vice-versa. Assembler é uma instância especializada do Mapper padrão também mencionado em Patterns of Enterprise Application Architecture .... "

e Prática: Transferência Data Object

Além disso, eu não usei isso por mim, mas você pode querer verificar para fora AutoMapper como bem.

Answer 2

Parece razoável para mim. Em LINQ to SQL, objetos de negócios são derivadas do DTO pelo uso de classes parciais.

Answer 3

"Então eu iria derivar meus objetos de negócios desses DTOs" tem em mente que DTOs pode parecer diferente do BO que pode conter propriedades de 2 ou 3 BO