El propósito de una capa de servicios y ASP.NET MVC 2

Question

En un esfuerzo por comprender MVC 2 y tratar de conseguir mi empresa a adoptarlo como una plataforma viable para el desarrollo futuro, he estado haciendo un montón de lectura últimamente. Después de haber trabajado con ASP.NET bastante exclusivamente para los últimos años, que tenía que ponerse a hacer.

Actualmente, entender el patrón de repositorio, modelos, controladores, anotaciones de datos, etc. Pero hay una cosa que me está impidiendo por completo la comprensión suficiente para empezar a trabajar en una aplicación de referencia.

La primera es el patrón de servicio de capa. He leído muchos blogs y preguntas aquí en desbordamiento de pila, pero sigo sin entender por completo el propósito de este patrón. Vi toda la serie de vídeo a MVCCentral sobre la aplicación Rastreador de golf y también miraba el código de demostración se registró y se ve a mí como la capa de servicio es más que otro envoltorio alrededor del patrón repositorio que no realiza ningún trabajo en absoluto.

También leer este post: http: //www.asp. net / Aprender / MVC / tutorial-38-cs.aspx y parecía responder a un tanto mi pregunta, sin embargo, si usted está utilizando anotaciones de datos para realizar su validación, esto parece innecesario.

Le he buscado demostraciones, postes, etc., pero me parece que no puede encontrar cualquier cosa que simplemente explica el patrón y me da evidencia convincente para utilizarlo.

Por favor alguien puede proporcionar con un segundo grado (bueno, quizás quinto grado) razones para utilizar este modelo, lo que iba a perder si no lo hago, y lo que ganar si lo hago?

Answer 1

En un patrón MVC tiene responsabilidades separó entre los 3 jugadores:. Modelo, Vista y Controlador

El modelo es responsable de hacer las cosas de negocios, la vista presenta los resultados de la empresa (siempre que también se introduce en el negocio del usuario), mientras que el controlador actúa como el pegamento entre el modelo y la vista, que separa el funcionamiento interno de cada de la otra.

El modelo es generalmente respaldado por una base de datos por lo que tiene algunas DAOs acceso eso. Su empresa hace algo así ... ... de negocios y almacena o recupera datos en / desde la base de datos.

Pero, ¿quién coordina las DAOs? ¿El controlador? ¡No! El modelo debe.

Introduzca la capa de servicio. La capa de servicios proporcionará un servicio de alto servicio al controlador y gestionará otros jugadores (nivel inferior) (DAO, otros servicios, etc.) detrás de las escenas. Contiene la lógica empresarial de la aplicación.

¿Qué pasa si no lo usa?

Se tendrá que poner en algún lugar de la lógica de negocio y la víctima suele ser el controlador.

Si el controlador está centrada web que tendrá que recibir su entrada y proporcionar la respuesta HTTP peticiones, respuestas. Pero lo que si quiero llamar a mi aplicación (y obtener acceso a la empresa que proporciona) desde una aplicación de Windows que se comunica con RPC o alguna otra cosa? ¿Entonces que?

Bueno, tendrá que volver a escribir el controlador y hacer que el agnóstico cliente lógica. Sin embargo, con la capa de servicio que ya tiene. Yyou no es necesario volver a escribir las cosas.

La capa de servicio proporciona comunicación con DTOs que no están vinculados a una implementación del controlador específico. Si el controlador (no importa qué tipo de controlador) proporciona los datos apropiados (no mater la fuente) de su capa de servicios hará todo lo que proporciona un servicio a la persona que llama y ocultando la persona que llama desde todas las responsabilidades de la lógica de negocio en cuestión.

Answer 2

Tengo que decir que estoy de acuerdo con DPB con lo anterior, la capa de envoltura es decir servicio es reutilizable, mockable, actualmente estoy en el proceso de inclusión de esta capa interior de mi aplicación ... aquí están algunos de los problemas / necesidades I am reflexionar sobre (muy rápidamente: p) que podrían estar fuera de ayuda para youeself ...
1. múltiples portales (por ejemplo portal Bloggers, portal del cliente, portal interno) que serán necesarios para ser accedidos por muchos usuarios diferentes. Todos ellos deben estar separadas las aplicaciones ASP.NET MVC (un requisito importante)
2. Dentro de las aplicaciones propias algunas llamadas a la base de datos será similar, los métodos y la forma en que los datos se manejan desde la capa de repositorio. Sin duda, algunos controladores de cada módulo / portal hará exactamente o una versión sobrecargada de la misma llamada, por lo tanto, la posible necesidad de una capa de servicio (código para las interfaces) que voy a continuación, compilar en un proyecto de clase separada.
3. Si se crea un proyecto de clase separada para mi capa de servicio que pueda necesitar para hacer lo mismo para la capa de datos o combinarla con la capa de servicio y mantener el modelo de distancia del proyecto Web en sí. Al menos así como mi proyecto crece puedo tirar la capa de acceso de datos (es decir LinqToSql -> NHibernate), o un miembro de lata equipo sin tener que trabajar en cualquier código en cualquier otro proyecto. El inconveniente podría ser que podían volar todo lol ...