O que usar no lugar do DTO?

Programação Arquitetura
#1

Olá pessoal, tudo bem? Tenho lido que DTO é considerado um anti-pattern quando aplicado em ambientes não distribuídos. Porém, eu utilizo DTOs spara comunicar a DAL com a BLL. Caso retornasse da DAL um objeto de negócio, estaria fazendo uma camada mais baixa depender de uma camada mais alta. Dessa forma, o que usar no lugar do DTO para comunicação do DAL com a BLL e da BLL com a camada de apresentação?

#2

use a própria entity da sua persistência, com o adivindo do ejb 3 entity com annotation, quando a mesma não esta attached ao repositório de dados, ela faz o serviçco de DTO VO o que seja.

[s]

#3

O que seria DAL e BLL?

#4

DAL é Data Access Layer e BLL é Business Logic Layer. Gostaria de saber qual a alternativa para DTOs, sem utilizar frameworks.

#5

Exato. Mas é uma escolha que você tem que fazer: vale a pena eu ter código duplicado só para manter dependências fluindo em uma só direção?

Se você achar que vale a pena duplicar código (o que eu não concordo de maneira geral, apesar de haverem casos onde pode fazer sentido) existem outras maneiras de fazer isso. Uma que já usei com sucesso é fazer a Camada de Persistência (sua DAL, um termo muito popular em .Net) gerar um memento que é utilizado para restaurar o estado do objeto de negócios. Note que o memento em questão não é um objeto burro.

Outro detalhe interessante é que se você usa Hibernate, JPA, NHibernate ou coisa parecida sua Camada de Persistência é quase que toda implementada pelo framework. Com a qualidade atual deste tipo de ferramenta a questão da existência de uma Camada de persistência bem definida fica cada vez mais sutil.

#6

Hmmm, interessante :wink: Você tem algum exemplo que faça comunicação entre camadas através de Memento? Com relação a utilizar frameworks, eu não queria usar por questões didáticas mesmo, pois gostaria que está fazendo o projeto entendesse bem a arquitetura em camadas.

Obrigado

#7

Não tenho o exemplo mas se você está criando um exemplo para aprender a gerenciar dependências então pode tentar escrever algo simples e colar aqui. Basicamente a idéia é que a Camada de Persist6encia cria e retorna Mementos para a Camada de negócios, que os usa para definir o estado dos objetos de negócio. ALgo como:

//camada de negocios
class RepoitorioUsuarios{
public Usuario getPorLogin(String login){
UsuarioMemento estado daoUsuario.getPorLogin(login);
Usuario usuarioCriado =new Usuario(estado);
return usuarioCriado;
}
}

Mas volto a lembrar que só recomendo este tipo de coisa para situações muito específicas.

#8

Aqui vai uma idéia do meu código, para você ver que o objeto que é passado entre as camadas é “burro”:

Camada de DTO

public class Usuario {
private String usuarioID;
public String getUsuarioId() {
return usuarioID;
}
private String nome;
public String getNome() {
return nome;
}
public Usuario(String usuarioID, String usuarioNome) {
this.usuarioID = usuarioID;
this.usuarioNome = usuarioNome;
}
}

Camada DAL

public UsuarioDAL {
public ArrayList retornaUsuarios(){
…
}
}

Camada BLL

public UsuarioBLL {

   public ArrayList<Usuario> retornaUsuarios () {            
        UsuarioDAL usuarioDAL = DALFactory.UsuarioDAL.Create();
        return usuarioDAL.retornaUsuarios();
   }

}

#9

Alguns pontos:

  1. Não existe necessidade de “Camada de DTO”, até porque se existisse você ia cair no mesmo problema de relação invertida entre Camadas, se você for fazer algo aprecido com isso provavelmente é melhor deixar estes objetos (que não são DTOs porque este padrão é alo diferente) dentro da Camada de Persistência

  2. Não existe necessidade dos sufixos nas classes, não sei se você etá apenas tentando explicitar neste exemplo mas é bom deixar claro.

  3. Apesar de resolver o problema da dependência invertida entre Negócios e Persistência você acaba criando um problema. Usuario nasce na persistência e navega até a interface, é um anti-pattern conhecido como “Mochileiro das Galáxias” (http://fragmental.tw/2008/09/01/layering-layers/ e http://www.slideshare.net/pcalcado/arquitetura-de-camadas-em-java-ee/). O uso do memento remove este problema.

  4. O seu Usuário deve contêr regras de negócio. Se ele contêm regras de negócio e está fora da Camada de Negócios você ainda tem o problema de dependência invertida, se ele não possui regras de negócio você possui um modelo anêmico. A idéia do memento ajuda aqui também.

Seja como for, eu reafirmo que só recomendaria algo assim em casos muito específicos. A complexidade que se faz necessária para resolver um problema mais teórico do que prático não se paga, na minha opinião.

#10

Valew pcalcado :slight_smile: Agora com relação a desenvolver essa solução apenas em casos específicos, você diz a separação em camadas ou a utilização de Value Objects?

Obrigado mais uma vez pelas dicas :wink:

#11

Apenas em casos específicos é importante manter o fluxo de dependências entre Camadas seguindo sempre em uma direção (i.e. não ter Persistência dependendo de Negócios). Nestes casos específicos usar o TO é uma das possibilidades, assim como o memento que mencionei.

#12

Beleza, valew pela força!! Vou ver se utilizo esse padrão Memento.

#13

Apenas em casos específicos é importante manter o fluxo de dependências entre Camadas seguindo sempre em uma direção (i.e. não ter Persistência dependendo de Negócios). Nestes casos específicos usar o TO é uma das possibilidades, assim como o memento que mencionei.[/quote]

O que você diz com relação a busca de dados na camada de persistência (ex: todos os usuários cadastrados no mes de julho de 2007)? Não estariamos criando uma dependencia entre ambas as camadas? Pois essa busca é uma regra de negócio e depende da persistência, não?

#14

A regra de negócio em si não fica na persistência, a persistência é só um serviço utilizado por ela.

Imagine que uma dada regra diga que o arquivo gerado pelo processamento X deve ser salvo no diretório Y e com permisão de leitura apenas. O filesystem é quem te dá a possibilidade de gravar um arquivo no diretório seguindo um dado critério mas o filesystem é só um serviço, ele não apresenta regra de negócio.

#15

[quote=pcalcado]
Se você achar que vale a pena duplicar código (o que eu não concordo de maneira geral, apesar de haverem casos onde pode fazer sentido) existem outras maneiras de fazer isso. Uma que já usei com sucesso é fazer a Camada de Persistência (sua DAL, um termo muito popular em .Net) gerar um memento que é utilizado para restaurar o estado do objeto de negócios. Note que o memento em questão não é um objeto burro[/quote]

Fala Calçado,

Que tipo de inteligência entra no memento para ele poder ser classificado como um objeto não-burro?

#16

[quote=domingos.neto]
Fala Calçado,

Que tipo de inteligência entra no memento para ele poder ser classificado como um objeto não-burro?[/quote]

Leia a descricao do padrao:
http://en.wikipedia.org/wiki/Memento_pattern

#17