O TNF faz uso de DTOs (Data Transfer Objects) em sua estrutura para fazer a comunicação entre as camadas.

A utilização de DTOs proveem um isolamento, respeitando assim o modelo de multicamadas evitando que a aplicação manipule diretamente as entidades de negócio.

Para suporte a essa estrutura instale via nuget o pacote Tnf.Dto disponível em: https://www.myget.org/F/tnf/api/v3/index.json.

Porque Utilizar?

Abstração da camada de domínio

DTOs fornecem uma maneira eficiente de abstrair objetos de domínio da camada de apresentação. Mesmo que você queira alterar completamente a camada de apresentação, você pode continuar com as camadas de domínio e de aplicação existentes. Como o oposto, você pode reescrever sua camada de domínio, alterar completamente o esquema de banco de dados, entidades e estrutura de ORM sem qualquer alteração na camada de apresentação, contanto que os contratos (assinaturas de métodos e DTOs) de seus serviços permaneçam inalterados.

Data hiding

Pense que você tenha uma entidade de usuário com propriedades Id, Nome e campos de Senha. Se o método ObterTodosUsuarios() de um serviço de aplicação chamado UsuarioAppService retornar uma Lista <Usuario>, qualquer pessoa pode ver senhas de todos os usuários, mesmo que você não a mostre na tela. 

Não se trata apenas de segurança, trata-se de ocultar dados. O serviço de aplicação deve retornar à camada de apresentação o que ele precisa. Não mais, nem menos. 

 Problemas com serialização e lazy load

Quando você faz o retorno de um dado em sua aplicação, geralmente esta informação tem de ser serializada para algum formato (JSON, SOAP), para que assim ela seja exposta através de um serviço para que algum cliente a consuma.

Em sua aplicação real, suas entidades terão referências umas às outras. A entidade do usuário pode ter uma referência a suas funções. Portanto, se você deseja serializar o usuário, suas funções também são serializadas podendo expor informações a quem consome.

Para o caso de estar trabalhando com algum framework ORM, a maioria deles contem suporte a lazy load dando abertura para que entidades sejam carregas de forma errada, trazendo muitas estruturas para a sua aplicação sem que elas sejam necessárias.

O uso de DTOs evitam problemas como os descritos acima porque são criados para retornar estruturas especificas de dados para que nenhuma informação excessiva seja trafegada erroneamente.

Estrutura para Envio e Resposta de Mensagens

No pacote Tnf.Dto os seguintes objetos:

DtoRequestBase

Essa classe representa todo objeto de envio tratado como "request" em sua aplicação. Você pode realizar a herança dessa classe ao criar um parâmetro para a entrada de um método por exemplo.

Notification

Representa uma notificação. Principalmente usada para colocar o Notification pattern em prática retornando estruturas de notificações ao invés de exceções pela aplicação.

Internamente esta classe contém uma estrutura como: Code, Message, Exception e Internal Code.

DtoResponseBase

Essa classe representa todo objeto de envio tratado como "response" em sua aplicação.

Quando você conter um método de validação por exemplo em um serviço, que deve retornar notificações caso a entidade não esteja apta a ser inserida, você pode criar um classe que representa essa resposta fazendo a herança dessa estrutura.

Essa classe possui internamente uma estrutura de Notifications com métodos que possibilitam o gerenciamento e validação de erros como: AddNotification e ErrorExists.

Caso você não deseje realizar a herança da classe você pode utilizar ela de forma genérica: DtoResponseBase<TResult>, onde TResult será uma propriedade nomeada Data para retorno de alguma estrutura existente.