Objectos de transferência de dados e métodos de serviço transaccionais

Question

Existe alguma maneira realmente prática para evitar o uso de DTOs, ao passar dados através de métodos de serviço transacionais Hibernate apoiados? Em outras palavras, são DTOs a única solução não-hacky para evitar problemas de inicialização lenta?

Eu acho que as duas alternativas populares para DTOs e as razões pelas quais eu realmente não gosto deles são:

1. Sessão aberta no modo padrão. Isso eu não gosto de como eu gostaria de manter os métodos do serviço verdadeiramente transacional (ou seja, a sessão Hibernate está comprometida e fechou quando sai do método). Isto é principalmente porque eu gostaria de não ter que se preocupar com transações se eu, por exemplo, necessidade de publicar o serviço como um serviço web mais tarde.

2. Passando domínio / objetos de negócios através de métodos de serviço em vez de DTOs e ansioso buscar os atributos necessários / propriedades. Isso é um pouco melhor. No entanto, em uma hierarquia de objetos de domínio não-trivial com as relações entidade complicadas a busca ansiosa tem para algum lugar stop. E quando isso acontecer, eu não posso ver como isso não iria transformar muito rapidamente em um hackaton completa substituição de entidades com referência ids em todo o lugar.

Estou faltando alguma coisa ou estão DTOs Na verdade, a abordagem só sólida do ponto de vista da manutenção?

Answer 1

A única maneira de realmente usar entidades de ponta a ponta é usar algo um pouco mais sofisticado do que OpenSessionInView. Na minha experiência, você vai ter de gerir a sessão de hibernação manualmente no nível do aplicativo. OpenSessionInView só vai te dar a mesma sessão para um pedido. Depois disso você terá que ser constantemente recolocar à sessão atual. Dê uma olhada em Seam e conversas, ou implementar seu próprio gestão Session Hibernate. Atualmente, gerenciar manualmente nossas sessões com base em quando um assistente começa e termina e usar Spring AOP para anexar sessões para os fios certos na hora certa (sessões não são thread-safe, não uma boa mistura com AJAX)

WebServices, por outro lado certamente vai precisar de alguma forma de DTO. Eu não vejo uma maneira de contornar isso. As entidades podem olhar como POJOs, mas não são realmente, serialização-los pode variar de difícil quase impossível. Basta criar DTOs que se encaixam com o objetivo do método de serviço e ser feito com ele.

Pessoalmente, eu não acho que o padrão DTO é terrível, se você está apenas fazendo um site é viável para ir de ponta a ponta com entidades e pode até comprar algum desempenho, mas se você gostaria de uma arquitetura mais flexível , vara com DTOs.

Answer 2

Repositórios, Serviços e Controladores devem ser os lugares que lidam com o seu núcleo aplicativo (Hibernate Session pode certamente ser usado como a totalidade de sua camada de repositório, se você gosta).

Vistas não é suposto estar a lidar com o seu núcleo aplicativo, o modelo de domínio. Eles não devem ser lidar com os objetos vivos, mas com um não-live representação, adaptada dos objetos vivos. Visualizações devem ser entregues apenas os dados de que necessitam, no formato especial que eles precisam. Você deve construir DTOs para seus pontos de vista. Esse padrão também é conhecido como Model View, para contrastar com modelo de domínio.

Para facilitar a sua vida, pode haver bibliotecas ou frameworks que pode auto-map do seu modelo de domínio objetos a seus objetos vista modelo, e de volta. Em .NET, não é um framework open source chamado AutoMapper atualmente em desenvolvimento; Eu não tenho certeza do que existe para Java.

Answer 3

Se você relaxar sua exigência para fechar a sessão, você ainda pode usar sessão aberta na vista e apenas cometer tudo em suas transações de serviços. A sessão ainda estará disponível para preguiçoso buscar, mas todas as suas transações será completa. Mas se você estiver indo para mudar para um serviço web, então você precisa de carga ansiosos todas as suas entidades de qualquer maneira. DTOs apenas forçá-lo a carga conscientemente ansioso e evitar a preguiça acidental.

Assim, linha de fundo, se você tiver cuidado, você pode pular os DTOs em ambos os ambientes, mas eu provavelmente iria ficar com sessão aberta em vista e preocupações sobre os serviços web quando eles realmente tornar-se uma exigência.

Answer 4

Eu amo a idéia de DTOs, mas eu sempre senti que eles não foram muito bem aceitos ou apreciado por outros desenvolvedores desde a implementação dessa abordagem adequadamente todo o caminho para o banco de dados geralmente requer um grande esforço. É por isso que eu criei Chama-Persistência Entidade Vistas que lhe permitem DTOs modelo como interfaces que mapeiam para o modelo de entidade JPA de uma maneira eficiente. Você pode aplicar uma visão entidade para uma consulta e a consulta será adaptado de forma que ele só vai buscar o estado realmente necessário, ao invés de todo o estado e mapear isso em Java.

Usando vistas entidade você não precisa a sessão aberta na vista de anti-padrão, porque a estrutura desejada é carregado ansiosamente. Desde há nenhuma entidade objetos envolvidos, também haverá nenhum problema de carregamento lento.

Uma vez que o modelo de entidade, muitas vezes é tão semelhante ao modelo DTO em estágios iniciais de desenvolvimento, muitas vezes eu vejo os desenvolvedores simplesmente ignorar a criação de um modelo DTO separado como eles tentam evitar o aborrecimento. Assim que as preocupações transversais, como auditoria, estatísticas ou denormalizations pousar no modelo de entidade ou a quantidade de dados no modelo de entidade cresce muito maior do que você realmente precisa para casos de uso da entidade, os desenvolvedores executar em problemas.

blogue

Você vai com certeza como um postar sobre esse assunto eu escrevi há algum tempo.