Post já nasce datado, mas só faz sentido para agora mesmo. Passei uns 10 anos da minha vida programando na linguagem Java e nos últimos 3 anos eu peguei poucos projetos, mas o que me impressiona nesses poucos projetos é que as coisas não mudam, inclusive a tara por patterns desnecessários e antipatterns.

Comecemos por Nomenclatura

Se voce chama sua classes de WhateverController, WhateverService e ou WhateverDAO, voce está usando notação hungara desnecessária e complicando a modelagem do seu negócio. Se o seu framework te obriga a nomear as classes com sufixos ou prefixos, ele está errado e é melhor procurar uma solução.

Se voce chama classes como WhateverModel ou WhateverEntity aí voce está estragando a amizade, se mate.

Se voce tem uma classe chamada Whatever e tem propriedades como nameWhatever, leia urgente Clean Code.

 

BOLOVO

As pessoas criavam entidades chamadas WhateverManager por não saberem orientação a objetos, se existe isso no seu projeto na maioria das vezes não tem muito o que fazer, mude de emprego ou de projeto. Mas… se for corajoso comece a refatorar isso guiado por testes, o livro “Growing Object-Oriented Software, Guided by Tests” vai te ajudar bastante. O Paulo Silveira e o Phillip Calçado nomearam esse anti-pattern de BOLOVO.

DAO

DAO é o pattern inútil quando falamos de negócios, principalmente CRUD. A não ser que você esteja codando Framework ou comittando em projetos como o Hibernate, voce não precisa escrever DAO. Voce usa Hibernate, a Session é seu DAO.

Se voce precisa de uma entidade para agrupar alguma lógica de ORM mais complexa no seu negócio – como algumas transações com rollback lógicos, uma alternativa é Repository. Mas por favor, leia o artigo do Phillip primeiro e não faça WhateverRepository. Não há problema nenhum voce ter Criteria dentro de um controller por exemplo, afinal isso é um pattern bem estabelecido e o mapeamento um-pra-um com outra entidade só vai complicar e não traz ganho algum.

Só uma dica aproveitando o tema ORM, o Hibernate trabalha e sempre trabalhou com convenções usando anotações, então não precisa mapear tudo. Basta um @Entity na maioria das vezes. Nos relacionamentos observe se ele já não mapeia tranquilo apenas com o @ManyToOne e diminua o ruído.

Em termos de Patterns, por mais caduco que já esteja, o PoEAA do Fowler ainda reina.

 

Interface e Implementação

Existe uma boa prática como guia que é desenvolver orientado a interface, só que isso não é lei e deve ser usado o bom senso como sempre. A maioria dos desenvolvedores criam a Interface Whatever e uma – e apenas uma – implementação WhateverImpl. Isso é desnecessário e muita gente nem sabe que o Spring sempre funcionou injetar em classes concretas e não apenas em Interface. Deixe a Interface gritar na sua cara para refatorar.

Service e Domain Driven Design

Aqui que mora o perigo, sempre quando eu vejo WhateverService a implementação dessa classe é o mesmo código do antigo WhateverManager. Depois que Domain Driven Design fez sucesso todo mundo finje que modela o domínio.

As classes do seu domínio devem e podem ter métodos de negócios, se ela apenas tem propriedades é sinal do BOLOVO e representa uma tabela do banco de dados vitaminada. Um Service não é a parte de negócios do seu domain, a grosso modo de explicar o código dele explodiu na sua cara por manipular duas ou mais entidades e não ser responsabilidade de nenhuma delas.

ANUNCIO EM LETRAS GARRAFAIS

Cuidado com os livros que eu indiquei, quando foram escritos o Hibernate e o Spring estavam nascendo ou ainda não tinham nascidos, portanto leia com moderação. Várias coisas já forma implementadas pelos Frameworks e não vá fazer uma roda por cima de outra roda.

TL;DR

Cuidado com o código que voce escreve, faça-o guiado por testes, leia bons livros de Orientação a objetos e Patterns. Não escreva código igual aos outros porque é assim que todo mundo faz.

Typically chemist’s shop can sale to you with discreet treatments for various soundness problems. There are numerous of safe online pharmacies that will deliver medications to your address. There are divers medicines for each afflictions. Learn more about “viagra manufacturer coupon“. Maybe “viagra discount coupons” is a extremely complicated problem. Matters, like “coupons for viagra“, are united numerous types of health problems. If you need to take recipe medications, ask your pharmacist to check your testosterone levels before. Sometimes the treatment options may include erectile dysfunction remedies or a suction device that helps get an hard-on. Keep in mind web-site which is ready to sell erectile dysfunction drugs like Viagra without a recipe is fraudulent. When you purchase from an unknown web-site, you run the risk of getting counterfeit remedies.