asp.net - route - tag helpers asp net core 2
El propósito de una capa de servicio y ASP.NET MVC 2 (2)
Debo decir que estoy de acuerdo con dpb con lo anterior, el envoltorio, es decir, la capa de servicio es reutilizable, burlable, actualmente estoy en el proceso de incluir esta capa dentro de mi aplicación ... estos son algunos de los problemas / requisitos sobre los que estoy reflexionando (muy rápido: p) que podría ser de ayuda para usted mismo ...
1. Múltiples portales (por ejemplo, portal de Bloggers, portal de cliente, portal interno) que serán necesarios para que accedan muchos usuarios diferentes. Todos deben ser aplicaciones ASP.NET MVC separadas (un requisito importante)
2. Dentro de las propias aplicaciones, algunas llamadas a la base de datos serán similares, los métodos y la forma en que se manejan los datos desde la capa Repositorio. Sin duda, algunos controladores de cada módulo / portal harán una versión exactamente o una versión sobrecargada de la misma llamada, de ahí la posible necesidad de una capa de servicio (código para interfaces) que luego compilaré en un proyecto de clase separado.
3. Si creo un proyecto de clase separado para mi capa de servicio, es posible que necesite hacer lo mismo para la capa de datos o combinarla con la capa de servicio y mantener el modelo alejado del proyecto web. Al menos de esta manera a medida que mi proyecto crezca, puedo descartar la capa de acceso a datos (es decir, LinqToSql -> NHibernate), o un miembro del equipo puede hacerlo sin trabajar en ningún código en ningún otro proyecto. El inconveniente podría ser que podrían explotar todo jajaja ...
En un esfuerzo por comprender MVC 2 y tratar de hacer que mi empresa lo adopte como una plataforma viable para el desarrollo futuro, he estado leyendo mucho últimamente. Después de haber trabajado con ASP.NET de manera bastante exclusiva durante los últimos años, tuve que ponerme al día.
Actualmente, entiendo el patrón del repositorio, los modelos, los controladores, las anotaciones de datos, etc. Pero hay una cosa que me impide entender completamente lo suficiente como para comenzar a trabajar en una aplicación de referencia.
El primero es el patrón de la capa de servicio. He leído muchas publicaciones de blog y preguntas aquí en Stack Overflow, pero todavía no entiendo completamente el propósito de este patrón. Vi toda la serie de videos en MVCCentral en la aplicación Golf Tracker y también miré el código de demostración que publicó y me parece que la capa de servicio es solo otra envoltura alrededor del patrón de repositorio que no realiza ningún trabajo en absoluto.
También leí esta publicación: http://www.asp.net/Learn/mvc/tutorial-38-cs.aspx y parecía responder algo a mi pregunta, sin embargo, si está utilizando anotaciones de datos para realizar su validación, esto parece innecesario
He buscado demostraciones, publicaciones, etc. pero parece que no puedo encontrar nada que simplemente explique el patrón y me da pruebas contundentes para usarlo.
¿Puede alguien proporcionarme una razón de 2 ° grado (vale, quizás 5 ° grado) para usar este patrón, qué perdería si no lo hago y qué ganaría si lo hiciera?
En un patrón MVC tienes responsabilidades separadas entre los 3 jugadores: Modelo, Vista y Controlador.
El Modelo es responsable de hacer las cosas de negocios, la Vista presenta los resultados del negocio (proporcionando también información al negocio del usuario) mientras el Controlador actúa como el pegamento entre el Modelo y la Vista, separando el funcionamiento interno de cada uno de el otro.
El Modelo generalmente está respaldado por una base de datos, por lo que tiene algunos DAO accediendo a eso. Su negocio hace ... bueno ... negocios y almacena o recupera datos en / desde la base de datos.
¿Pero quién coordina los DAO? ¿El controlador? ¡No! El modelo debería.
Ingrese la capa de Servicio. La capa de Servicio proporcionará un alto servicio al controlador y administrará otros jugadores (nivel inferior) (DAO, otros servicios, etc.) detrás de escena. Contiene la lógica comercial de tu aplicación.
¿Qué pasa si no lo usas?
Tendrá que poner la lógica de negocios en algún lugar y la víctima generalmente es el controlador.
Si el controlador está centrado en la web, tendrá que recibir su entrada y proporcionar respuesta como solicitudes HTTP, respuestas. Pero, ¿qué sucede 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 cliente lógico sea independiente. Pero con la capa de servicio ya tienes eso. No necesitas volver a escribir las cosas.
La capa de servicio proporciona comunicación con los DTO que no están vinculados a una implementación de controlador específica. Si el controlador (no importa qué tipo de controlador) proporcione los datos apropiados (sin importar la fuente), su capa de servicio hará lo suyo brindando un servicio a la persona que llama y ocultando a la persona que llama de todas las responsabilidades de la lógica comercial involucrada.