Tem que implementou uma aplicação de n camadas com MVC corretamente?

Question

Sendo muito familiarizado com padrões de design e arquitetura, estou tendo dificuldade em explicar aos outros exatamente como meu último aplicativo foi projetado. Tenho alternado entre o pensamento é um n-tier puro, puro MVC e n-tier com MVC na camada de apresentação. Atualmente eu acho que o último é correto, mas eu quero pensamentos de desenvolvedores mais experientes.

Como funciona:

1. navegador envia pedido HTTP para Tomcat. Mapas do pedido via web.xml para um servlet (que eu chamo controlador)
2. O controlador instancia um ou mais métodos de objetos de negócios e convida estes, ou seja customerBO.getById(12) que novamente irá executar lógica de negócios / validação antes de chamar um ou mais métodos DAO, ou seja customerDAO.getById(12). Os BO retorna uma lista de CustomerVO é para o controlador
3. O controlador prepara atributos para a vista (JSP) (request.setAttribute("customers", customers);) e escolhe um arquivo .jsp para uso que por sua vez irá iterar na lista e processar XHTML volta para o navegador.

Estrutura (minha proposta / compreensão)

Apresentação nível : usando atualmente o que eu acho que é um MVC web-implementação: servlets (controladores), JSP (vistas) ea minha própria implementação de formas OO XHTML (. Ie CustomerForm) mentiras aqui. Deve ser possível usar um Swing / JavaFX / Flex GUI mudando esta camada de apresentação e sem a necessidade de mudar nada nas camadas abaixo.

Logic nível : Dividido em duas camadas, com Business Objects (BO) no topo. Responsável pela lógica de negócios, mas eu não encontrei muito para colocar aqui além de validação de entrada desde que o aplicativo consiste principalmente de ações CRUD simples ... Em muitos casos, os métodos apenas chamar um método com o mesmo nome na camada DAO.

classes DAO com métodos CRUD, que por sua vez contacta com a camada de dados abaixo. Também tem um convertToVO (ResultSet res) métodos que realizam ORM a partir da base de dados e para (listas de objectos de valor). Todos os métodos de levar objetos de valor como entrada, ou seja, customerDAO-> save (eleitor) e devolver o eleitor actualizado em caso de sucesso e nula em caso de falha.

camada de dados : os dados de fundo é armazenado em um banco de dados ou como arquivos XML. Eu não "codificado" nada aqui, a não ser alguns procedimentos e gatilhos MySQL armazenado.

Perguntas (além do um no título):

1. O M em MVC. Eu não tenho certeza se posso chamar isso de n-tier MVC quando os modelos são listas / do VO retornou de objetos de negócios na camada de lógica? São os modelos obrigados a residir na camada de apresentação quando o controlador / vista é aqui? E podem os modelos de formulário na camada de apresentação ser chamado de modelos? Se então; são ambos os formulários e listas de BO para ser considerado como o M em MVC?
2. No meu entendimento, no MVC a vista é suposto para observar o modelo e atualização sobre a mudança, mas isso não é possível em uma aplicação web onde a vista é uma página XHTML prestados? Por sua vez, leva-me a pergunta: é MVC implementado de forma diferente para aplicações web versus aplicações desktop regulares
?
3. Não estou usando um padrão Front Controller quando todas as solicitações HTTP são explicitamente mapeados em web.xml certo? Para usar o Front Controller I necessidade de encaminhar todas as solicitações para um servlet / controlador padrão que, por sua vez evalutes a solicitação e chama outro controlador?
4. A camada de negócios senti um pouco "inútil" no meu aplicativo. O que você normalmente colocado nesta camada / objetos? Deve-se sempre ter uma camada de negócios? Eu sei que deve conter "lógica de negócios", mas o que é isso exatamente? Eu só executar a validação de entrada e uma instanciar ou mais DAOs e chama os métodos apropriados sobre eles ...

Eu percebo que é MVC frameworks como Struts para Java, mas uma vez que este meu primeiro web-aplicativo Java eu ??tentei obter uma compreensão mais profunda de como as coisas funcionam. Olhando em retrospecto, eu espero que você possa responder a algumas das perguntas que eu tropecei em cima.

Answer 1

Eu não tenho certeza se posso chamar isso de n-tier MVC quando os modelos são listas / do VO retornou de objetos de negócios na camada de lógica

Aqueles são perfeitamente bons modelos. Eu também considerar as ActionForms em Struts ser modelos. ActionForms são o Struts usa para representar / formulários HTML modelo.

no MVC a vista é suposto para observar o modelo e atualização sobre a mudança, mas isso não é possível em um web-application

Sim, e isso é uma questão de debate para saber se você pode ter uma verdadeira MVC com aplicações web.

deve-se sempre ter uma camada de negócios?

Depende do tipo de aplicação. Algumas aplicações são banco de dados orientado, e são essencialmente uma interface de usuário para o banco de dados. Nesse caso, há muito pouco a lógica de negócios necessários.

Camada de dados:

Os procedimentos armazenados não são realmente parte do código de camada de dados. Você deve ser a criação de objetos de acesso a dados (DAOs) que são chamados pelos objetos de negócios. Os DAOs chamar os procedimentos armazenados. Além disso, as interfaces DAO deve dar nenhuma dica para os objetos de negócios quanto ao local onde os dados são armazenados, mesmo que seja um sistema de banco de dados ou arquivo ou de algum serviço web.

Answer 2

Eu acho que você está recebendo-se pendurado na terminologia. O padrão MVC (eu acredito) pré-data o aplicativo web clássico arco que você descreve. Ele para ser que as pessoas chamadas web app arco MVC 2 (Modelo 2 etc.) para diferenciá-lo do padrão MVC originais ...

ver este link> http://www.javaranch.com/drive/servlet/ # MVC2

HTH