Duvida sobre violação de Camadas + J2EE

Eric Evans fala em seu livro Domain Driven Design que a camada de aplicação pode sim acessar serviços da camada de infraestrutura, onde persistência é apenas um dos serviços fornecidos pela mesma.

Aqui tem uma imagem do diagrama do livro:
http://www.elbandit.co.uk/images/JimmyDDD.jpg

Trecho extraído do livro Domain Driven Design Quickly:

Não era necessário uma justificativa tão rigorosa para fazer o que você quer fazer, mas uma vez que foi solicitada, aí está.

tnaires:

Trecho extraído do livro Domain Driven Design Quickly:

Não era necessário uma justificativa tão rigorosa para fazer o que você quer fazer, mas uma vez que foi solicitada, aí está.

Olá tnaires, mas neste exemplo ele fala sobre ApplicationLayer, o que subtende por Façades, BussinesDelegate ,etc…

Mas no meu caso estou falando de Servlet/Action, que são da Camada de Apresentação, e não da Camada de Aplicação, por isso perguntei se seria uma violação de camada.

O que gostaria de saber é se eu tivesse uma estrutura do tipo

Web->Action -> Persistencia -> SGDB

Seria uma violação de camada?

Valeu

Putz… Foi mal, li apresentação e entendi aplicação…

Nesse caso, segundo o DDD, teoricamente não seria adequado. Mas pense em duas coisas:

1. Um sistema que segue o padrão Layered Architecture do DDD deve ter necessariamente uma camada de aplicação, de onde você acessaria a infraestrutura conforme acima. Mas você deve se questionar para quê serve a camada de aplicação e se você precisa dela de fato. Se você chegar à conclusão de que não precisa, o jeito é você acessar a infraestrutura diretamente da camada de apresentação - leia-se, actions/managed beans;
2. Veja que no diagrama do livro há também uma conexão entre as camadas de apresentação e infraestrutura.

Resumidamente, se você precisa de uma camada de aplicação, não faz sentido acessar a infraestrutura a partir da apresentação.

tnaires:

Putz… Foi mal, li apresentação e entendi aplicação…

Nesse caso, segundo o DDD, teoricamente não seria adequado. Mas pense em duas coisas:

1. Um sistema que segue o padrão Layered Architecture do DDD deve ter necessariamente uma camada de aplicação, de onde você acessaria a infraestrutura conforme acima. Mas você deve se questionar para quê serve a camada de aplicação e se você precisa dela de fato. Se você chegar à conclusão de que não precisa, o jeito é você acessar a infraestrutura diretamente da camada de apresentação - leia-se, actions/managed beans;
2. Veja que no diagrama do livro há também uma conexão entre as camadas de apresentação e infraestrutura.

Resumidamente, se você precisa de uma camada de aplicação, não faz sentido acessar a infraestrutura a partir da apresentação.

Olá Tarso, obrigado pelas respostas. Então na minha opinião, acredito que só há necessidade de criar uma Camada de Aplicação, quando se trabalha com duas interfaces por exemplo como Swing e Html, ai tudo bem, pois não posso acoplar a camada de apresentação a minha interface, pois posso ter nomes diferentes nas camadas.

Então acho que no meu caso é justificado acessar a camada de persistencia diretamente. Como fala no artigo, uma camada não de nivel mais alto nao deve depender de outra de nivel mais baixo e sim de abstrações, então neste caso seria acessar uma interface Dao correto?

Esse é um dos motivos, mas não é o único. Por exemplo, a camada de aplicação é bastante útil para centralizar outros aspectos de infraestrutura que não persistência, como controle de transação e/ou logging. Você pode escrever sua aplicação sem essa camada, mas tem que arcar com os prejuízos de não adotá-la, se eles existirem. Dificilmente você sentirá esses prejuízos se seu sistema for apenas CRUD.

No meu caso controlo transação com Filters, mas achei interessante fazer loggin, na camada de Aplicação. Me responde outra coisa digamos que tenha na minha interface Dao findByCriterion(Criterion c), poderia ser de responsabilidade da camada de aplicação montar essses criterios tipo assim, usando JSF.

Camada de Apresentação

class FuncionarioBean{
  ApplicationLayer funcionarioFaçade //exemplo.
 public List<Funcionario> findByName(){

    funcionarioFacade.findByName(funcionario.getNome());
 
}

class FuncionarioFacade {
  private Dao funcionarioDao;

   public list<Funcionario> findBYName(String nome){
   Criterion c=Restrictions.ilike("nome",nome,MatchMode.ANYWHERE));
   return funcionarioDao.findByName(c); 
 
  }
}

   
}

O problema aqui seria a duplicação de metodos, mas tbm acho estranho criar um Criterion dentro da camada de aplicação, caso quissese usar um metodo deste tipo, qual seria a camada mais aconselhavel para se criar o Criterion?

Valeu, tem me ajudado muito!

danielbussade:

Me responde outra coisa digamos que tenha na minha interface Dao findByCriterion(Criterion c), poderia ser de responsabilidade da camada de aplicação montar essses criterios tipo assim, usando JSF.

(…)

O problema aqui seria a duplicação de metodos, mas tbm acho estranho criar um Criterion dentro da camada de aplicação, caso quissese usar um metodo deste tipo, qual seria a camada mais aconselhavel para se criar o Criterion?

tnaires:

danielbussade:

Me responde outra coisa digamos que tenha na minha interface Dao findByCriterion(Criterion c), poderia ser de responsabilidade da camada de aplicação montar essses criterios tipo assim, usando JSF.

(…)

O problema aqui seria a duplicação de metodos, mas tbm acho estranho criar um Criterion dentro da camada de aplicação, caso quissese usar um metodo deste tipo, qual seria a camada mais aconselhavel para se criar o Criterion?

Aí é melhor você jogar no repositório, que é onde estão localizados os métodos de consulta. A implementação do repositório se encarrega de utilizar o mecanismo de consulta referente à tecnologia de persistência que você está usando, seja Hibernate, JPA ou JDBC.

Então Tnaires, mas o repositorio não seria apenas uma interface? Antes eu teria que criar o Criterion, esse que e o problema onde criar este criterion.

Como você faz atualmente?

danielbussade:

Então Tnaires, mas o repositorio não seria apenas uma interface? Antes eu teria que criar o Criterion, esse que e o problema onde criar este criterion.

Como você faz atualmente?

Quando você constrói o repositório, é prudente sim fazer com que as classes externas ao pacote enxerguem apenas a interface, mas a implementação, apesar de não ser visível externamente, existe. E é ela que utilizará Criteria, HQL, SQL, XML ou o que for. E a vantagem de usar interfaces é que, se um dia sua aplicação deixar de utilizar JDBC para utilizar Hibernate, teoricamente será preciso apenas trocar as implementações dos repositórios - claro que outras mudanças relativas à configuração também serão necessárias.

package domain;

public interface CustomerRepository {
    Collection<Customer> findByName(String name);
}

package domain;

class HibernateCustomerRepository implements CustomerRepository {
    public Collection<Customer> findByName(String name) {
        // Código que cria um objeto Criteria e recupera os clientes cujo nome começam com "name"

        return result;
    }
}

package domain;

public class RepositoryFactory {
    public static CustomerRepository getCustomerRepository() {
        return new HibernateCustomerRepository();
    }
}

package domain;

class JDBCCustomerRepository implements CustomerRepository {
    public Collection<Customer> findByName(String name) {
        // Código que cria um objeto PreparedStatement e executa um SQL para recuperar os clientes cujo nome começam com "name"

        return result;
    }
}

package domain;

public class RepositoryFactory {
    public static CustomerRepository getCustomerRepository() {
        //return new HibernateCustomerRepository();
        return new JDBCCustomerRepository();
    }
}

tnaires:

danielbussade:

Então Tnaires, mas o repositorio não seria apenas uma interface? Antes eu teria que criar o Criterion, esse que e o problema onde criar este criterion.

Como você faz atualmente?

Sim, o repositório pode ser uma interface, mas o que é uma interface sem sua implementação? Não funciona. Por exemplo, você acha que java.sql.Connection é apenas uma interface? O driver JDBC tem uma classe que implementa a interface Connection, mas ela não está visível pra nós.

Quando você constrói o repositório, é prudente sim fazer com que as classes externas ao pacote enxerguem apenas a interface, mas a implementação, apesar de não ser visível externamente, existe. E é ela que utilizará Criteria, HQL, SQL, XML ou o que for. E a vantagem de usar interfaces é que, se um dia sua aplicação deixar de utilizar JDBC para utilizar Hibernate, teoricamente será preciso apenas trocar as implementações dos repositórios - claro que outras mudanças relativas à configuração também serão necessárias.

Vejamos um exemplo. Temos um cadastro de clientes e temos uma consulta por nome do cliente. Haverá uma interface pública para o repositório de clientes:

package domain;

public interface CustomerRepository {
    Collection<Customer> findByName(String name);
}

Teremos sua implementação invisível para as classes fora do pacote. Note a visibilidade default para a classe:

package domain;

class HibernateCustomerRepository implements CustomerRepository {
    public Collection<Customer> findByName(String name) {
        // Código que cria um objeto Criteria e recupera os clientes cujo nome começam com "name"

        return result;
    }
}

E agora temos uma das possíveis formas de disponibilizar o repositório para as camadas que o utilizam, através de uma factory:

package domain;

public class RepositoryFactory {
    public static CustomerRepository getCustomerRepository() {
        return new HibernateCustomerRepository();
    }
}

E se um dia der uma doida e tivermos que mudar de Hibernate para JDBC, será preciso criar uma nova implementação para o repositório...

package domain;

class JDBCCustomerRepository implements CustomerRepository {
    public Collection<Customer> findByName(String name) {
        // Código que cria um objeto PreparedStatement e executa um SQL para recuperar os clientes cujo nome começam com "name"

        return result;
    }
}

... e mudar o código da fábrica:

package domain;

public class RepositoryFactory {
    public static CustomerRepository getCustomerRepository() {
        //return new HibernateCustomerRepository();
        return new JDBCCustomerRepository();
    }
}

Foi um exemplo muito simples, mas que ilustra o que quero dizer.

Olá tnaires, é exatamente assim que faço. Mas o que quis dizer foi o seguinte, digamos que amanha vc queira pesquisar por login, e depois por cidade, teria que criar tres metodos certo?

findByLogin,
findByCidade

O que estou querendo fazer é ter um metodo bem generico, no repository, tipo como falei.

getByCriterion(Criterion);

e na implementacao seria

Criteria c=session.createCriteria(classe);
c.add(criterion);

Assim teria uma pesquisa generica podendo colocar OrderBy , Projections, etc.

O problema é que tenho q entregar este criterio pronto, vindo de outro lugar. Ai pergunto onde seria o melhro lugar para montar esse criterion.

Hj estou montando na Apresentação mas isso viola camadas, além de ficar feio.

Entendeu a minha duvida!

Onde, poderia colocar a montagem desses criterions?

Cara, como falei antes, não tem jeito. O melhor lugar pra montar esse Criterion é dentro dos métodos do repositório, como os que você citou: findByLogin, findByCidade, etc.
Agora o método genérico que você quer construir pode ficar em dois locais:

1. Uma classe de utilitários;
2. Uma classe abstrata - digamos HibernateRepository - da qual todas as implementações dos repositórios herdariam.

Afinal, voce ja decidiu se vai de ActiveRecord ou DDD?

Olá, onde você estava vendo ActiveRecord aqui?

Pois é, Daniel, eu tambem tenho essa mesma duvida sobre onde criar os criterions. Eu achei uma maneira que me ajuda a manter a interface do repositorio mais limpa, mas nao sei se é a ideal, talvez ainda nao seja.

Eu crio objetos “buscadores” que recebem os parametros e criam os criterions, depois sao passados para os repositorios com um clienteRepository.findByCriterios(buscadorDeCliente).

por exemplo:

buscadorDeCliente.setRazaoSocial("Pepsi");
buscadorDeCliente.setCidade("Sao Paulo");

Depois ele possui um metodo que retorna uma hql ou criteria ou sql ou qualquer coisa dependendo da implementacao, baseado nos parametros que foram informados.

A desvantagem é que preciso escrever um pra cada entidade da aplicacao.

E detalhe: Usuario salva outro usuário? Acho que AR, se trate de o usuário “se salvar”. ex.: user.save();

MrDataFlex:

danielbussade:

3- Criar um metodo save dentro De Usuario(ActiveRecord), e minha action/servlet chamar Usuario.save(usuario);

E detalhe: Usuario salva outro usuário? Acho que AR, se trate de o usuário “se salvar”. ex.: user.save();

Exato, erro de Ctrl+ C e CTRL + V meu!

Orbigado!

Não tenho certeza se eu entendi a dúvida sobre criteria mas uma coisa que recomendo ao utilizá-lo em DDD é utilizar uma interface de Specifiation na Camada de Negócios e implementá-la com um Query Object na Persistência. É um equivalente à dobradinha Repositório/DAO.

Acho difícil estarem falando de DDD neste caso. Pelo que entendi a única motivação para o mecanismo de busca parte do cliente da camada de aplicação.

A lição que aprendi hoje, sempre se questione quanto a real necessidade de tantas abstrações que na verdade se mostram inúteis.

É justamente o que tento fazer, o problema é que a unica coisa que minha interface tem em relacao ao pattern specification é o nome. Meu Repositorio tem um metoto chamado findBySpecification(Specification s) e dentro desse metodo eu faco um casting para uma implementacao especifica do Hibernate, que cria e retorna um criteria, como eu comentei no meu post anterior.

É melhor do que inchar a interface do repositorio com dezenas de metodos de consulta, mas ainda nao consegui acertar esse ponto.

Olá shoes, como ficaria a interface de uma Specification neste caso?