Primavera formBackingObject, Criação de Objetos de Negócios e Fábricas
-
19-09-2019 - |
Pergunta
Projeto questão para o uso da Business Objects como formBackingObjects em um SimpleFormController Primavera.
responsabilidade do nosso controlador é permitir que um usuário final para adicionar um novo objeto de negócios para a nossa aplicação web.
Por isso, estamos passando nosso Business Object que o formBackingObject (HttpServletRequest pedido) método. No entanto, nós funcionamos em um dilema.
A fábrica que estamos usando para criar a nossa nova Business Object impõe as regras de negócios que alguns dos atributos não pode ser nulo. Mas desde que nós não sabemos o que o Usuário Final quer entrar temos sido passando em "padrões razoáveis", como "Digite o nome que você quiser", mas que parece Hackie / icky na melhor das hipóteses.
O que é um desenvolvedor para fazer? Eu sinto como se este é o frango problema clássico / ovo.
Todos os objetos nosso negócio são baseados fora de Interfaces, devemos criar um stub que representa o objeto de negócios, passar o Stub como o formBackingObject, e, em seguida, passar o Stub para a fábrica em um formulário enviar? Ou não devemos passar nada no formBackingObject e, em seguida, reunir manualmente as informações enviadas a partir do pedido?
Quaisquer outras ideias razoáveis ??/ padrões?
Obrigado pelo seu tempo.
Solução
eu definitivamente não escolher a opção de não usar um formBackingObject e reunir as informações manualmente -. Que eliminaria uma grande parte do poder que faz Spring MVC que vale a pena, em primeiro lugar
Se eu fosse você, gostaria apenas de fazer uma nova fábrica, ou método de fábrica, que é projetado especificamente para criar um "não inicializado" objeto de negócios, e usar isso como seu formBackingObject.
Outra abordagem que é amplamente utilizado não é usar um objeto de negócios como seu formBackingObject em tudo, mas criar um objeto de transporte distinto cujo único propósito é ser o formBackingObject (e, em seguida, adicionar um método de fábrica para o seu objeto de negócios que lhe permite inicializar-lo a partir do objecto de transporte). Uma das grandes vantagens deste é se o seu objeto de negócios tem uma árvore profunda de outros objetos dentro dele, isso pode torná-lo uma dor para usar como um formBackingObject. Se você criar um objeto de transporte separado apenas para uso como um formBackingObject, você pode dar-lhe uma estrutura mais plana muito.
Outras dicas
Use um objeto de comando (um simples POJO morto) para representar a entrada do usuário ao seu controlador. Então você pode usar a validação embutido para Spring MVC para se certificar de que todos os campos obrigatórios são fornecidos no objeto de comando. Se o comando passa a validação, então você pode mapeá-lo para a sua "Business Object" programaticamente (ou usando uma biblioteca de mapeamento de feijão como dozer ).
Desta forma, você pode lidar com a validação, submissões do usuário incompletas, etc., sem tocar ou modificar as classes de lógica de negócios / regras / serviços existentes. Isto permite-lhe manter a camada web separar essas camadas existentes.
Para referência, consulte o MVC tutorial , que toca em objetos de validação e de comando em Parte 4 .