80 votos

Modelo de la grasa / delgado controlador vs. capa de Servicio

He sido el desarrollo de aplicaciones empresariales para muchos años de uso .Net Mis aplicaciones suelen tener un modelo de dominio que contiene la asignación a las entidades de SQL DB tablas. Yo uso un modelo de Repositorio, la inyección de Dependencia y una capa de servicio.

Recientemente hemos comenzado a trabajar en MVC 3 proyectos y tuvimos un debate donde poner que la lógica. Me he topado con fina Controlador / Modelo de la GRASA de la arquitectura y se preguntaba cómo el servicio de capa de ajuste en

Opción 1 - Modelo de charlas a los servicios

El controlador es delgada, llama a los métodos de los modelos. Los modelos de "saber" cómo cargar themselfs de la DB y hablar a los repositorios o servicios. E. g. customerModel tiene una Carga(id) método de cargas y el cliente, y algunos de los niños objetos como GetContracts().

Opción 2 - Controlador de charlas a los servicios

Controlador solicita los Servicios para recuperar los objetos del modelo. La lógica de carga / almacenamiento, etc. Es en la capa de servicio. El modelo es un puro modelo de entidad de datos con el sólo.

¿Por qué la opción 1 es una mejor opción, sobre todo cuando hablamos de aplicaciones enterprise mi experiencia me dice que para separar las preocupaciones, mantener los modelos Y Controladores de lo más fino posible y tener servicios especializados de hacer la lógica de Negocio (imcl. La base de la interacción)

Gracias por todos los consejos y referencias a recursos.

92voto

one.beat.consumer Puntos 5612

Todo esto depende de la intención y los requisitos de su aplicación.

Dicho esto, aquí está mi sugerencia para "mediados de escala" (no en un restaurante local, y no de Twitter/Facebook) de aplicaciones web.

  1. Lean Dominio De Modelado

    Seco de a POCO el estilo de los objetos, preferiblemente ignorante de la arquitectura MVC de su aplicación web para permanecer como débilmente acoplados a partir de su aplicación concreta como sea posible.tal vez incluso de la biblioteca de clases repack-poder para el uso en una aplicación externa, por ejemplo un RESTO de la API a través de un Servicio Web WCF).

    "Modelo" en MVC con mayor precisión significa que el modelo del Controlador es consciente de y por lo tanto el modelo destinado a la Vista.

    En los más pequeños (a menudo Tutorial) aplicaciones de la entidad modelos de su "Application/Modelo de Dominio de la Capa" son a menudo las mismas instancias de objetos el controlador de barcos frente a una Vista.

    En grandes aplicaciones, los desarrolladores suelen emplear los principios de la arquitectura MVVM y comenzar a utilizar por separado de la Vista de los objetos del Modelo. Los controladores suelen llamar a los servicios de nivel medio que trabajar con lo desconocido entidades que están por debajo. En este escenario, la M en MVC con mayor precisión significa que el Modelo de Vista.

  2. Robusta Capa De Servicio

    Esto no significa obesos lógica, pero bien escrita el único propósito de los servicios. Mientras que la codificación de la lógica de negocios en servicios fuera de la modelo es un poco más "de procedimiento" que es puro "OOP", que ayuda mucho con acoplamiento flexible, pruebas y despliegue flexible (ex. n-nivel de implementación).

    En mi práctica personal, código de servicios tanto abajo en la capa de datos, la cual considero que mi comportamiento modelado de los objetos POCO (la persistencia de la mecánica, bajo nivel de validación, etc.), y alto nivel de servicios (negocios/función de flujo de trabajo) hasta cerca de la MVC mecánica.

  3. Lean Los Controladores

    Me aseguro de que mi controlador es simplemente el entrenador, que no es ni la play (servicios) o el jugador (modelo de entidad o modelo de vista), sino que simplemente decide quien juega en qué postura y a qué juegan a hacer. Mi controladores de hacer dos cosas:

    1. Llame a servicios que interactúan con la entidad/de los Modelos de dominio

    2. Preparar un Modelo de visualización de la Vista correspondiente.

    Incluso autenticado/autorizado de las acciones de los controladores se realiza a través de inyectar servicios/atributos.


EDIT 1:

Tenga en cuenta que esto no significa que su Entidad/Modelo de Dominio es o debe ser anémico. Orm, depósitos y fábricas, o de validación de estado de la mecánica son bienvenidos. Significa solamente para aplicaciones de escala moderada, el Modelo en MVC representa el modelo destinado a la controladora, a la mano de su punto de Vista.

Esperemos que este punto se calma Fowler apóstoles que creen que el anémico modelo de datos para ser un anti-patrón. Al mismo tiempo, hace reflexionar un poco más procesales ángulo de la programación orientada a objetos, donde es más puro para incluir el comportamiento en el modelado de las clases.

No hay una "verdad última", pero el uso de este patrón, usted encontrará que es fácil de construir, probar y desplegar sus aplicaciones, mientras que el mantenimiento de una gran cantidad de re-usabilidad y escalabilidad.


EDIT 2:

Dicho esto, incluso para un tamaño modesto, aplicaciones, más de la arquitectura (que una palabra nerds?) un sistema es demasiado común. Por ejemplo, envolver un ORM con un modelo de repositorio y, a continuación, escribir los servicios a utilizar el repositorio... todo esto es bueno para la separación de preocupación y tal, pero si el proyecto no requiere (y no es muy probable que pronto se requieren) tales cosas, no la construcción. No hay nada de malo con saltarse el repositorio de todos juntos, escritura fina servicios de negocios (ex. consulta de clases) en contra de un ORM, o incluso tener su controlador de hablar directamente con él. Todo depende de la escala.


EDIT 3:

Yo quería señalar que esta explicación y asesoramiento para el contexto de MVC del lado del servidor de la arquitectura como ASP.Net, no para clent marcos de lado como Knockout o la columna vertebral.

16voto

jgauffin Puntos 51913

Necesitas saber un poco más acerca de MVC antes de ir hacia adelante y discutir dónde poner todo. Bueno, si quieres seguir el patrón. De lo contrario, puede dejar de leer ahora.

El patrón es muy vagamente definido. No hay nada que dice que el controlador de vista de modelo o debería parecerse a la forma en que deberían ser estructurado. El patrón indica que se deben separar las piezas y cómo deben interactuar el uno con el otro. Así que vamos a ver en poco más acerca de lo que son (mi interpretación).

MVC

Modelo El modelo puede ser cualquier cosa. Puede ser un webservice, sus repositorios, las clases de servicio o, simplemente, su dominio de los modelos. El Modelo de todo lo que se utiliza para obtener la información que necesita. Considerar el "Modelo" como una capa en lugar de un solo objeto.

Controlador de El controlador es un pegamento. Se toma la información de la Modelo y la adapta a la vista y viceversa.

Ver La vista sólo debe representar lo que el usuario ve.

Hay que hacer notar que no se debe confundir el Modelo con la Vista de los Modelos. Microsoft debería realmente han denominado el "Modelo" de la carpeta "Viewmodel" ya que eso es lo que son. Yo no usaría la información del "Modelo" directamente en los puntos de vista. No hacerlo podría significar que usted tiene que cambiar el Modelo si se cambia la Vista y de la otra manera alrededor.

La respuesta

El modelo no es un modelo de vista, sino una capa. Todo lo que en el modelo se utiliza para recuperar la información necesaria para la vista. El controlador recibe la información y la pone en un único modelo de vista.

Un único controlador, la acción podría utilizar una o varias llamadas a la "Modelo" para ser capaz de reunir la información necesaria para la vista.

Lo que significa que su segunda opción es la más correcta cuando si deseas obtener una aplicación que es fácil de mantener y ampliar.

Tenga en cuenta que una capa de servicio no podría ser necesaria. Usted puede llamar a la O/M directamente de los controladores. Pero si se encuentra la duplicación de código o la obtención de controladores de grasa, basta con desplazar la lógica de una capa de servicio. Nada, pero el controlador va a ser afectados por el cambio ya se están utilizando modelos de vista.

0voto

Imre L Puntos 4130

Opción 1: Usted podría pensar que el modelo == el servicio. El modelo también ES la capa de negocio.

La opción 2 es un Modelo de Dominio Anémico anti-patrón. http://en.wikipedia.org/wiki/Anemic_domain_model

0voto

Sergey Kudriavtsev Puntos 6090

La opción 2 es lo que se describe como Grasa Estúpido Feo Controladores de arquitectura (Referencia al autor de esta expresión). Esta solución está generalmente en contra de MVC espíritu, ya que se rompe la separación de preocupaciones.

Iteramos.com

Iteramos es una comunidad de desarrolladores que busca expandir el conocimiento de la programación mas allá del inglés.
Tenemos una gran cantidad de contenido, y también puedes hacer tus propias preguntas o resolver las de los demás.

Powered by:

X