En caso de una capa de servicio de retorno Ver modelos para una aplicación MVC?

Question

Supongamos que tiene un proyecto ASP.NET MVC y está utilizando una capa de servicio, como en este gestor de contactos de tutorial en el sitio asp.net: http://www.asp.net/mvc/tutorials/iteration-4-make-the-application-loosely- acoplado-cs

Si usted tiene ViewModels para sus puntos de vista, es la capa de servicio el lugar apropiado para proporcionar a cada modelo de vista? Por ejemplo, en el ejemplo de código capa de servicio hay un método

    public IEnumerable<Contact> ListContacts()
    {
        return _repository.ListContacts();
    }

Si por el contrario quieres un IEnumerable, debe ir en la capa de servicio, o hay alguna otra parte que es la "correcta" lugar?

Tal vez más apropiadamente, si usted tiene un modelo de vista independiente para cada vista asociada con ContactController, debe ContactManagerService tener un método separado para volver cada modelo de vista? Si la capa de servicio no es el lugar adecuado, donde debe viewmodel objetos pueden inicializar para su uso por el controlador?

Answer 1

Generalmente, no.

Ver modelos tienen por objeto proporcionar información hacia y desde puntos de vista y debe ser específico para la aplicación, en comparación con el dominio general. Los controladores deben orquestar la interacción con los repositorios, servicios (Estoy haciendo algunas suposiciones de la definición de servicio aquí), etc y el mango de construcción y validación de modelos de vista, y también contienen la lógica de determinación vistas a prestar.

Por fugas de modelos de vista en una capa de "servicio", que están borrando sus capas y ahora has posible aplicación específica y presentación mezclado con lo que debería centrado con responsabilidades a nivel de dominio.

Answer 2

No, no lo creo. Los servicios deben cuidar sólo sobre el dominio del problema, no la vista que rinde resultados. Los valores de retorno deben expresarse en términos de objetos de dominio, no vistas.

Answer 3

De acuerdo con el enfoque tradicional o teoría sabia, ViewModel debe ser parte de capa de interfaz de usuario. Por lo menos el nombre lo dice.

Pero cuando se llega a la implementación de usted mismo con Entity Framework, MVC, depósito, etc., entonces se da cuenta de algo más.

Alguien tiene que asignar Modelos Entidad / DB con ViewModels (DTO menciona en el final). Si esto se realiza en [A] la capa de interfaz de usuario (por el controlador), o en [B] la capa de servicio?

voy con la opción B. La opción A es un no, no por el simple hecho de que varios modelos de entidades combinan entre sí para formar un modelo de vista. Es posible que no pasar datos innecesarios a la capa de interfaz de usuario, mientras que en la opción B, el servicio puede jugar con los datos y pasar sólo el / mínimo requerido para la capa de interfaz de usuario después de la cartografía (a la ViewModel).

Una vez más, vamos a ir con la opción A, puesto ViewModel en la capa de interfaz de usuario (y el modelo de entidad en la capa de servicio).

Si las necesidades capa de servicio para asignar al modelo de vista, a continuación, la capa de necesidad de servicio para acceder modelo de vista en la capa de interfaz de usuario. Qué biblioteca / proyecto? El modelo de vista debe estar en un proyecto separado en la capa de interfaz de usuario, y este proyecto tiene que ser referenciado por capa de servicios. Si el modelo de vista no está en un proyecto separado, entonces no hay referencia circular, por lo que no ir. Parece difícil de tener acceso a servicio de capa de la capa de interfaz de usuario, pero aún podríamos hacer frente a ella.

Pero lo que si hay otra aplicación utilizando la interfaz de usuario de este servicio? ¿Qué pasa si hay una aplicación móvil? ¿Qué tan diferente puede ser el modelo de vista? En caso de que el servicio de acceso a la misma vista del modelo de proyecto? ¿Todos los proyectos de interfaz de usuario acceder al mismo proyecto o modelo de vista que tienen su propio?

Después de estas consideraciones mi respuesta sería la de poner el proyecto en el modelo de vista capa de servicios. Cada capa de interfaz de usuario tiene que acceder a la capa de servicio de todos modos! Y podría haber una gran cantidad de ViewModels similares que todos ellos podrían utilizar (por lo tanto la cartografía se hace más fácil para la capa de servicio). Asignaciones se hacen a través de LINQ en estos días, que es otra ventaja.

Por último, hay esta discusión acerca de DTO. Y también sobre la anotación de datos en ViewModels. ViewModels con anotaciones de datos (Microsoft.Web.Mvc.DataAnnotations.dll) no pueden residir en la capa de servicio en lugar residen en la capa de interfaz de usuario (pero ComponentModel.DataAnnotations.dll pueden residir en la capa de servicio). Si todos los proyectos están en una solución (.sln), entonces no importa qué capa lo pones. En las aplicaciones empresariales, cada capa tendrá su propia solución.

Así DTO en realidad es un modelo de vista sobre todo porque habrá uno en uno entre los dos (decir con AutoMapper). Una vez más DTO todavía tiene la lógica necesaria para la interfaz de usuario (o múltiples aplicaciones) y reside en la Capa de Servicio. Y la capa de interfaz de usuario modelo de vista (si utilizamos Microsoft.Web.Mvc.DataAnnotations.dll) es sólo para copiar los datos de DTO, con un poco de 'comportamiento' / atributos añadidos a la misma.

[Ahora bien, esta discusión está a punto de dar un giro interesante leer sobre ...: I]

Y no creo que los atributos de datos de anotación son sólo para la interfaz de usuario. Si limita la validación usando System.ComponentModel.DataAnnotations.dll a continuación, el mismo modelo de vista también se puede utilizar para front-end y validación backend (eliminando así UI-residente-ViewModel-copy-de-DTO). Por otra parte atributos también se pueden utilizar en los modelos entidad. Por ejemplo: el uso de .tt, modelos de datos de Entity Framework pueden ser generados automáticamente con la validación de los atributos para hacer algunas validaciones DB como máximo de longitud antes de enviarlo a la parte de atrás. Otra ventaja es que si la validación backend cambia en el PP después .tt (lee específicos de DB y crear el atributo para la clase de entidad) automáticamente tomará eso. Esto puede obligar a las pruebas de unidad de interfaz de usuario de validación a fallar, así, que es una gran ventaja (para que podamos corregirlo e informar a todos UIS / consumidores en lugar de olvido y no accidentalmente). Sí, la discusión se está moviendo hacia un diseño de la estructura buena. Como se puede ver es todo lo relacionado con:. En cuanto al nivel de la validación, la estrategia de prueba de unidad, la estrategia de almacenamiento en caché, etc.

Aunque no está directamente relacionado con el cuestionorte. 'ViewModel Fachada' mencionado en este debe vigilar de enlace de canal 9 también vale la pena explorar. Se inicia exactamente en 11 minutos 49 segundos en el video. Debido a que este sería el siguiente paso / pensado una vez que su pregunta actual dada anteriormente se solucionaron: '¿Cómo organizar ViewModels?'

También en su ejemplo "_repository.ListContacts ()" es devolver un modelo de vista desde el repositorio. Esto no es una forma madura. Repositorios deben proporcionar modelos o modelos entidad de base de datos. Esto se convierte a modelos de vista y es esta vista del modelo que se devuelve por la capa de servicio.

Answer 4

supongo que depende de lo que se tiene en cuenta los "servicios" a ser. Nunca me ha gustado el término servicio en el contexto de una sola clase; es increíblemente vago y no te dice mucho sobre el propósito real de la clase.

Si la "capa de servicio" es una capa física, tales como un servicio web, a continuación, en absoluto; servicios en un contexto SOA deben exponer a las operaciones de dominio / negocio, no datos y no la lógica de presentación. Pero si servicio solo se está utilizando como un concepto abstracto para un nivel adicional de encapsulación, no veo ningún problema con el uso de la forma que desribe.

Eso sí, no mezclar conceptos. Si sus ofertas de servicios con modelos de vista, entonces debe ser un servicio de presentación y estar en capas sobre la parte superior de la real Modelo, tocar nunca directamente la base de datos o cualquier lógica de negocio.

Answer 5

Esto ha recorrido un poco de un "depende" en la que trabajo - hemos generalmente tenía un controlador consumidor algún servicio (s) - combinando después de regresar DTO en un 'modelo de vista' que luego se van pasando al cliente - ya sea a través de resultado JSON, o unido en la plantilla de la maquinilla de afeitar.

cosa es, aproximadamente el 80% del tiempo - la asignación de DTO a ViewModel ha sido 1-1. Estamos empezando a moverse hacia 'Cuando sea necesario, simplemente consumir el DTO directamente, pero cuando el DTO y lo que necesitamos en nuestro cliente / vista no coinciden - entonces se crea un modelo de vista y hacer el mapeo entre objetos como sea necesario'.

A pesar de que todavía no estoy convencido de que esta es la mejor solución o derecha - '? Estamos Simplemente añadiendo X a la DTO para satisfacer las necesidades de la vista', ya que termina dando lugar a algunas discusiones acaloradas de