Mejor enfoque para separar el modelo, la vista y el controlador

Question

Estoy pensando en el mejor enfoque para separar Model View y Controller-for Java y usar Eclipse, si hace alguna diferencia.

que utilizan para separar MVC de cada tipo dentro de su propio paquete, pero me pongo a pensar que esto no es el mejor enfoque:

• com.company.client (controler)
• com. company.client.model

• com.company.client.view

• com.company.another (controler)

• com.compa ny.another.model

• com.company.another.view

• com.company.yetAnother (controler)

• com.company.yetAnother.model
• com.company.yetAnother.view

(asumir una gran cantidad de diferentes paquetes, cada uno con su propio punto de vista y modelo)

pensé en uso:

• com.company.client
• com.company.another

• com.company.yetAnother

• com.company.model.client

• com.company.model. otra

• com.company.model.yetAnother

• com.company.view.client

• com.company.view.another
• com.company.view.yetAnother

Incluso pensé en poner el controlador, el modelo y la vista en diferentes proyectos . Tal vez sería aún más modular, y estaría más seguro de que la vista no está usando el controlador, por ejemplo (ya que el proyecto del controlador incluiría la vista, pero no al revés).

Entonces, ¿cuál es el mejor enfoque para separar M, V y C?

(considerar aplicaciones web y de escritorio, no sólo web)

Answer 1

The Graal Quest! Tiene dos matriz tridimensional con verticales (MVC) y horizontal (reglas de negocio) capas ...

• no he encontrado una respuesta estricta
• Su primer acercamiento se ve bien porque modular orientado (tal vez no intencional)
• Para una pequeña aplicación para el segundo, aunque quizás aceptable

Para mí la respuesta es una palabra: dependencias
Siga buscando en "diseño/estrategia del paquete"; "Granularidad"

Algunos lectura

• http://techdistrict.kirkk.com/2009/08/05/modularity-patterns/
• http://techdistrict.kirkk.com/2010/04/22/granularity-architectures-nemesis/

Recomiendo encarecidamente este:

• http://www.jgoodies.com/articles/patterns-and-binding-old.pdf

GOOD LUCK!

Answer 2

¿Está sólo se refiere a "separar" el Modelo, Vista y Controlador por lo que la denominación y paquetes de ir? Esto parece ser todo lo que preguntas.

que tienden a presentar a mis paquetes, tales como:

• com.company.app.domain - dominio de las clases del modelo para la aplicación, basta con Java Beans (captadores y definidores única, muy poca o ninguna lógica). Esto se usa como "el modelo" en toda la aplicación y lo usa cada capa de mi aplicación.
• com.company.app.service - Clases de nivel de servicio de la aplicación, que contienen lógica comercial.
• com.company.app.web.controllers - Clases de controladores para mi aplicación web. Otras clases específicas de la web se incluyen en otros subpaquetes de web.
• com.company.app.dao - DAO interfaces para acceder a las clases del modelo de dominio - es decir, para recuperar un usuario de la base de datos, etc.

Dentro de cada una de ellas, a veces los paquetes se desglosan por área de la aplicación o en grupos más pequeños basado en la funcionalidad, lo que parece apropiado.

Answer 3

Creo que también es importante considerar cómo le gustaría utilizar el hecho de que ha dividido los módulos por separado en su código base. ES DECIR. ¿Qué tipo de utilidad, aparte de la calidad del código básico, está buscando explotar en función de su esquema de empaquetado?

La mayoría de las aplicaciones en las que trabajo siguen la siguiente estructura de empaquetado: * .domain, * .service.subservice, * .dao, * .web.controllers. Esto funciona muy bien para rastrear dependencias cíclicas en la base de código y/o dependencias que fluyen de forma incorrecta (controlador que golpea el dao sin la indirección de un servicio). También proporciona una estructura de empaquetado muy simple que es útil y no engorrosa.

Sin embargo, esto se rompe cuando se analizan las evaluaciones de impacto de dependencia automáticas. Actualmente uso DependencyFinder con un poco de código personalizado para comparar dos archivos jar antes de QA. DependencyFinder extraerá todos los métodos modificados y sus dependencias de primer nivel asociadas. El código personalizado tiene que activarse para asignar los métodos/clases modificados a las funciones de negocio y escupe un archivo de gramática graphviz para representar un conjunto de cambios basado en función comercial, un gráfico de dependencia para QA. Actualmente, intentamos utilizar los resultados de la herramienta para la planificación de pruebas de regresión inteligente, particularmente para los defectos de producción que se están moviendo a producción sin una prueba de regresión de varias semanas completa.

La estructura de directorios que propone hará que el segundo caso sea mucho más fácil. Sin embargo, también encontré que la mayor parte de mi equipo de desarrollo no le importa dependencias en absoluto, por lo que la utilidad del corrector automático de dependencia puede variar :)

Answer 4

Aquí hay un ejemplo usando un diseñoCapas Arquitectura con tres capas (aplicación, dominio, ui):

en el modelo-vista-controlador (MVC) el modelo sería en una capa inferior, tal como com.company.myapp.domain. Todas las otras capas pueden acceder al Modelo. Entonces la Vista y el Controlador estarían en com.company.myapp.ui. Eso significa que la clase Controller siempre está en la misma capa que View. No confunda el controlador MVC con otras clases de controlador que proporcionan lógica de aplicación y residen en la capa de aplicación. Por ejemplo, SalesController en com.company.myapp.application, que proporciona operaciones del sistema para manejar las ventas.

Ahora puede imaginar que SalesController cambia algunos datos en su modelo (actualiza una Venta) y el modelo informa al MVC-Controller que actualiza la Vista.

Nota: Todos los modelos están en la capa domain. Todas las vistas y los controladores MVC están en la capa ui. Los controladores lógicos de negocios se encuentran en la capa application. Por supuesto, puedes subdividir estas tres capas más si tienes muchas clases con preocupaciones diferentes.

Espero que esto ayude.

Answer 5

Suponiendo que haya que tratar con un proyecto no trivial, creo que su problema de haber dos aspectos a considerar en forma conjunta para la creación de la arquitectura y la calidad del código:

• nombrar
• modularización

Para nombrar, intento tener la mayor cohesión en cada espacio de nombres y seguir el Common Closure Principle y el Common Reuse Principle.

Para la modularización Trato de utilizar un módulo para cada tema arquitectónico principal del proyecto y nombro convenientemente sus paquetes.

MVC es un patrón de módulo de presentación que tiene como objetivo separar cómo el módulo de presentación controla el flujo, en qué modelos de datos se basa y cuál es la lógica relacionada con la vista.

En mi IDE de Java (por ejemplo, Eclipse) utilizo un proyecto por módulo, por lo que el módulo web será un proyecto y el módulo de escritorio será otro proyecto.En un proyecto web, por ejemplo, tengo un prefijo común, tales como:

com.mycompany.app.web 

y en ella tengo unas .controllers (o acciones), descendiente de un .models descendientes y así sucesivamente.

com.mycompany.app.web.models 
com.mycompany.app.web.actions 

Si uso una base de datos, confío en un módulo DAO, otro proyecto. El módulo DAO no tiene una presentación, por lo que no tiene un enfoque MVC. Persiste en los objetos de dominio, por lo que tal vez dependa de un módulo de dominio. En estos módulos utilizo prefijos como la siguiente:

com.mycompany.app.domain 
com.mycompany.app.dao 

Trato de no confundir Modelo en MVC con la aplicación dominio; ellos no son lo mismo

Otro error común es confundir Controlador con Business Logic; la lógica empresarial debe colocarse en un módulo y compartirse entre los módulos de presentación, el controlador en un espacio de nombre del módulo de presentación (web o escritorio).

A Modelo (en MVC, un modelo de vista) es un objeto utilizado por una vista para mostrar algo que el usuario: se puede contener uno, una combinación o una colección de dominio objetos. El controlador usa módulos disponibles (DAO, etc.) para construir una vista Modelo y luego lo pasa a Ver.

Ver entonces puede confiar sólo en su Modelo (sólo uno, expresamente creado por el controlador) y pregunte por modelos a los controladores (el único capaz de construir modelos). Ver, especialmente para presentaciones web, a menudo está codificado en una combinación de idiomas, por lo que parte del código podría permanecer fuera de las convenciones de nomenclatura.

Answer 6

Piensa en cómo te desarrollas. ¿Desarrollas por Controlador/Modelo/Vista? ¿O se desarrolla por módulo? Lo más probable es que desarrolles en un módulo y no en una capa MVC. Entonces, por lo tanto, creo que ahí radica su respuesta. Trate de mantener los nombres de sus paquetes lo más cerca posible de los módulos que representa su sistema (lo que ya está haciendo, supongo). No es necesario que le muestre las opciones arquitectónicas en los nombres de sus paquetes.

Mostrando nombres de los módulos y las cuestiones de dominio en empaquetar crear una base de código mantenible y consistente.