Boa tarde pessoal, acabei de ler o livro Introdução à Arquitetura e Design de Software “Uma visão sobre a plataforma JAVA”, do pessoal da Caelum e do Guj, aprendi muitas coisas e recomendo.
Mais me surgoiu uma duvida, seguinte:
No Capitulo 3 tópico 3.5 Cuidado com o Modelo Anemico
Os autores defendem a implementação de métodos de negocios nas classes de modelo, para que o encapsulamento e getters e setters não sejam criados a toa, achei a proposta muito interessante, mais fiquei com uma duvida até que ponto isso atrapalha no modelo MVC, pois o modelo prega que na camada Controller é que deve ficar os métodos de negocio, caso eu deixe minhas classes de modelo inteligentes, a minha classe de negocio ficaria somente para a passagem de objetos de uma camada para outra como se fossem TDO’s, sendo que TDO’s são muito usados em aplicações destribuidas. como vocês trabalham com Classes de modelo mais inteligentes ou com modelo anemico.
qualquer opinião critica e sugestão é bem vinda!!!
Acho que seu problema está em pensar desta forma: "MVC, pois o modelo prega que na camada Controller é que deve ficar os métodos de negocio"
Controller serve para ORQUESTRAÇÃO.
icarocd boa noite, não intendi muito bem o conceito de orquestração, você poderia me explicar como você trabalha com a arquitetura MVC, pois encontrei uma pancada de definições diferentes, mais até hoje não cheguei a conclusão nenhuma.
Na teoria o conceito de MVC, puramente, não me parece ditar onde residem exatamente as regras de negócio da sua aplicação no sentido em que não delimita exatamente as fronteiras. Ou seja, o que está no M e no C, ou entre eles, fica em aberto. Mas, na prática, o que fazemos é adotar uma forma outra para os projetos conforme parece coerente.
Controller lida com o fluxo de informação entre View e o core da aplicação (seus domains e services). Ou seja, orquestra entradas e saídas de/para a aplicação, digamos assim.
A lógica de negócio deve estar isolada e não dependente dos seus acessos (view e controller), mesmo porque é possível termos diferentes view+controller para uma mesma aplicação.
A maioria dos projetos em que atuo são distribuídos, existindo um servidor para camada web e outro para aplicação, e os objetos que trafegam entre os 2 mundos são os famosos proxys.
Entao nossas entidades são todas anêmicas, e as classes que fazem acesso a banco de daods ficam no servidor de aplicação, populam o objeto de domínio com as informações obtidas e devolvem o proxy serializado para a camada web. Nós não usamos MVC, e sim uma arquitetura simples 3 camadas, web + negocio + DAO.
Nesse cenário, gostaria de saber se é possível fugir do modelo anêmico e como implementar um modelo rico neste caso.
Hoje em dia implementamos Repositorio e Service disso e aquilo pra tudo e na prática o modelo de entidades vai ficando consequentemente anêmico. Gostaria que o mundo fosse simples e não burocrático como o exemplo abaixo. Desconsiderando purismos e visões que as vezes são irreais na prática (dependendo do caso) em que as entidades não vao usar hibernate e/ou banco em outra aplicação, ou ainda ficar abstraindo framework de persistência sem real necessidade. Muitos casos como por exemplo apps móveis tem suas entidades enxutas para atender suas próprias necessidades de forma otimizada.
[code]public class Pedido {
atributos
…
…
public static List obterPedidosCancelados(dataInicial, dataFinal) {
return List usando criteria;
}
public static void fecharPedido(int id) {
altera status e faz algo mais;
}
}[/code]