Tenho procurado bastante sobre como fazer o melhor uso da POO, dos design patterns e dos princípios SOLID, entretanto parece que as infraestruturas do Java te forçam a modelar seu domínio de forma anêmica.
A minha impressão é que eu raramente faço uso (diretamente) dos princípios da OO.
Tenho um controller ou outro mecanismo de entrega como um handler de eventos por exemplo, que vai chamar um serviço com alguma lógica de negócio, utilizando os modelos de forma anêmica, se apoiando nos POJO com getters e setters, ao final disso tudo persisto em um DAO ou um Repositório…
muda-se os padrões de camada/arquitetura, mas a essência é sempre essa.
E mesmo que você queira criar DTOs ou outros tipos de modelos que não sejam ali do domínio, algum framework ou especificação vai querer que você tenha um POJO… ou pelo menos um construtor default.
Certamente que já utilizei de alguns padrões de projetos e de boas modelagens, mas são casos bem específicos do código…
Gostaria de saber se existe alguma forma limpa no Java de trazer isso para os modelos (ex: entidades da JPA/Hibernate) ou devo me conformar que a linguagem que eu utilizo teve toda essa estrutura comunitária criada e orientada ao padrão do POJO?
Use só o que for necessário pra atender bem os resultados. Se o chamado “modelo anêmico” for a forma mais ágil de manter seu projeto, use, independente do que papas da tecnologia ditam.
Eu por sempre ter usado banco de dados relacional, nunca vi necessidade de aumentar a complexidade com uso de modelo orientado a objetos. Basicamente escrevo SQL e jogo em uma classe que represente essa estrutura de dados específica, sem misturas. Lógica de negócio em uma classe de negócio separada, que pode usar ou não essas estruturas.
Onde trabalho, usamos o DDD, que é exatamente “fugir do modelo anêmico” e os resultados estão sendo ótimos até o momento. Mas, se for seguir, tem que entender bem o conceito senão dá problema. Caso o contrário, é melhor seguir a simplicidade conforme dito pelo @javaflex (que eu tb concordo e já usei bastante).
já trabalhei num empresa que não adotava o modelo anêmico, mas eles tinham frameworks próprios(e bem antigos, mas atendia a demanda), achei bem melhor juntar as propriedades da classe com seus comportamentos e validações, mas esse foi o único caso, como disse usava frameworks próprios, hoje trabalho com frameworks de mercado do ecossistema java e aqui só trabalhamos com modelo anêmico e criando interfaces a torto e a direito para cada camada de implementação, uma imp e uma interface para BO e uma imp e interface para DAO e um objeto para modelar a entidade de negócio e ainda de quebra alguns objetos a mais para a ferramenta que for usar(jdbcTemplate etc), acho bem custoso mas nesse caso não tem como fugir disso.
É o que eu tenho feito por toda minha carreira, mas o Java é uma linguagem muito poderosa e as vezes bate a sensação de que não exploramos todo o potencial dela. Só queria ver o que a comunidade anda fazendo em relação a isso. Sistemas orientado a dados, realmente não precisa muito mais do que um scrpt de transação com algumas regras.
Sim, é o que eu tento buscar, e nem é uma questão de ser purista ou não. O problema é que por mais que você concentre em criar um domínio bem encapsulado, coeso e rico em comportamento, em dado momento você vai ter que ceder para algum framework. Ex: JPA vai exigir que você crie um construtor default para conseguir recriar seus objetos em memória ao serem consultados do Banco de Dados e por aí vai.
A única vez que eu vi isso foi em uma situação parecida com a sua também! Antes do Android se popularizar, trabalhei em uma empresa focada em soluções mobile (Palm OS hauhauhaua), utilizavamos uma máquina virtual baseada em Java chamada TotalCross, como não tinha frameworks, toda a infraestrutura foi feita na unha. Nesse caso, os arquitetos do sistema priorizaram a modelagem e os componentes e funcionava muito bem para a época. Eu adorava trabalhar naquele sistema!
Óbvio que utilizar frameworks deu um ganho absurdo em nossas vidas, o sistema de injeção de dependências e componentização do Spring ou da JEE, as ferramentas ORM, esse bando de configuração embutida que a gente não precisa mais configurar uns 300 arquivos xml, tudo isso veio para melhorar nossas vidas, por isso que eu queria tentar juntar o melhor dos dois mundos.
Sempre preferi desenvolver orientado a banco, seja com VB, Delphi, Java, PHP, Java ou C#. É muito mais ágil de manter do que com modelo OO.
Nao é porque a linguagem é poderosa que voce vai usar um poder sem ter a necessidade, aumentando a complexidade do seu projeto a toa. Infelizmente é o que se vê muito por ai, complexidade técnica desnecessária ao invés de foco na funcionalidade. Quando pego um sistema dessa forma, com tempo vou libertando as funcionalidades do modelo OO, deixando tudo mais independente, sem firúlas de OOP, batendo os olhos direto na funcionalidade.