Boa tarde pessoa.
Estou com uma dúvida em uma implementação aqui e gostaria de saber se isso foge da definição dos patterns.
Essa aplicação está correta?
Esse meu método está dentro da minha classe CampaignDAOImpl
@SuppressWarnings("unchecked")
public List<CampaignDTO> listCampaignsByCustomer(Long customerID) {
List<Campaign> campaigns =
(List<Campaign>) getHibernateTemplate().findByCriteria(
DetachedCriteria.forClass(Campaign.class)
.add(Expression.eq(Campaign.PROP_CUSTOMER, customerID))
.setProjection(
Projections.projectionList()
.add(getCampaignProperties()))
);
return getCampaignDTOs(campaigns);
}
O DTO pode ser montado dentro de um DAO ou devo faze-lo no controller?
Abraços e obrigado!
Cara, eu populo o DTO dentro de um BO… e dentro desse BO é que eu acesso o DAO pra fazer a persistencia… mas isso é questão de arquitetura.
mais pra q dto se hoje as entity’s são pojo?
não vejo mais necessidade a tempos deste pattern.
DTO pq existem campos que nao tem relação nenhuma com o meu POJO.
E entidade é entidade…rs.
BO, como ficaria isso?
Eu gostaria de separar ao máximo as responsabilidades.
O objeto de negocio (entidade) não pode ser montado no DAO. Um DTO (objeto generico) pode.
A sua classe não é um DAO, é um Repositorio, já que não abstrai a tecnologia de persistencia e sim a consulta
a ela.
É correto um Repositorio criar objetos de negocio.
Não é correto o controler de apresentação tomar nenhuma medida relativa aos objetos do dominio excepto obter um objeto vazio, prenche-lo e delegar pesquisas por objetos já preenchidos.
BO - Business Objects, ou seja as regras de negócio da sua aplicação.
Segue um exemplo simples…
public class classeBO {
public ClasseDTO nomeDoMetodo(parametro) {
Session session = HibernateUtil.currentSession();
ClasseDTO classeDTO = new ClasseDTO ();
try {
ClasseTal classeTal = new ClasseTalDAO().nomeDoMetodoNoDAO(parametro, session);
//populando o DTO
classeDTO.setAtributo(classeTal.getAtributo());
classeDTO.setAtributo2(classeTal.getAtributo2());
classeDTO.setAtributo3(classeTal.getAtributo3());
// etc...
} catch (Exception e) {
e.printStackTrace();
}
return classeDTO;
}
}
Espero ter ajudado!
T+
Qual seria o motivo para você usar um DTO nem um BO neste caso? Se existem campos no DTO que não estão presentes no objeto de negócio (acho que você está usando a palavra POJO incorretamente. Seu DTO é um POJO também) isso mostra que existem coisas no seu domínio que não estão mapeadas nos seus objetos de negócio.
Ao invés de criar um DTO e um BO (a famosa proramação BOLOVO) use objeto de negócio do DAO até a interface.
nao ha motivo ALGUM de usar DTOs entre LAYERS… pra que separar esses dois? se tem coisas da sua entidade que nao tem no DTO e vice versa, basta mapear corretamente pro banco de dados, ou ignorar alguns campos.
DTOs vc usa entre TIERS se houver necessidade (o que eh raro hoje em dia com ejb3 ja que os entity beans sao serializaveis, e nao remotos)