Pregunta

Sé que esto puede sonar tonto, pero me resulta difícil entender la necesidad de una capa de servicio y sus diferencias con la capa de negocio.

Por lo tanto, estamos utilizando asp.net mvc 2 y tienen datos de la capa de acceso, que hace todo el de la consulta con la base de datos y luego tenemos la capa de negocio que tiene la lógica de negocio y validaciones que había que hacer. Por último tenemos la capa de presentación que básicamente tiene todos los puntos de vista. Además también tenemos algunos ayudantes, dtos y clases ViewModel en diferentes carpetas como una parte de nuestras bibliotecas. Pero he tratado de leer acerca de la arquitectura y parece que la capa de servicio es una parte importante de una arquitectura.

Lo único que entiendo es que una capa de servicio es algo que llama a todas las funciones. Pero no puedo ver realmente la necesidad de la capa de servicio en nuestra aplicación? O podría ser que ya existe y no puedo verlo ... ¿Puede alguien explicar con un ejemplo de cómo una capa de servicio es importante? ¿Cómo es diferente de una capa de negocio porque a partir de lo que he leído parece bastante similar? Si su en el primer necesaria en absoluto? Todo lo que tratamos de hacer es arquitecto nuestra aplicación de la mejor manera posible lo que son sus pensamientos y experiencias en él?

¿Fue útil?

Solución

Se trata de desacoplar su aplicación en sí contenía piezas, cada una definida por el requisito de hacer un trabajo muy bien.

Esto le permite aplicar patrones de diseño especializados y mejores prácticas para cada componente.

Por ejemplo, el trabajo de la capa de negocio es implementar la lógica de negocio. El punto final. Exponiendo una API diseñada para ser consumido por la capa de presentación no es su "preocupación".

Este papel de intermediario entre el se realiza mejor mediante una capa de servicio. Factoring a cabo esta capa especializada le permite aplicar patrones mucho más especializados para cada componente individual.

No hay necesidad de hacer las cosas de diseño de esta manera, pero la experiencia acumulada de la comunidad indica que el resultado es una aplicación que es mucho más fácil de desarrollar y mantener, ya que sabe exactamente lo que se espera que cada componente que hacer, incluso antes de empezar a programar la aplicación.

Cada capa debe hacer un trabajo muy bien. El papel de intermediario entre que realiza la capa de servicio es una de esas trabajo bien definido y que es la razón de su existencia: es una unidad de complejidad que se ha diseñado de la misma manera una y otra vez, en lugar de tener que reinventar la rueda cada vez, para mangle este papel con la lógica de negocio en el que no pertenece. Piense en la capa de servicio como un componente de mapeo. Es ajena a la lógica de negocio y no tiene cabida en sus clases, o en los controladores tampoco.

Además, como resultado de haber sido un factor fuera de la lógica de negocio, se obtiene objetos de negocio más simples que son más fáciles de usar por otras aplicaciones y servicios que consume el "negocio".

ASP.NET MVC no es más que una plataforma para que pueda escribir sus aplicaciones como componentes especializados.

Como resultado de este aumento de la comprensión de cómo especializarse componentes, los programas están evolucionando de un tazón de sopa primordial y los espaguetis en algo diferente y extraño. La complejidad que pueden abordar, mientras que todavía el uso de estructuras simples, es cada vez mayor. La evolución es cada vez va. Si la vida es algo que pasar, esto tiene que ser bueno, a fin de mantener las cosas en marcha.

Otros consejos

Se puede encontrar el término interesante Arquitectura astronauta .

El punto es, no quedar atrapado en todas estas "capas" que las personas esgrimen. Cada vez que tuvo otra capa a la aplicación, tiene que haber un propósito en ella.

Por ejemplo, algunas personas se combinan con éxito los conceptos de una capa de acceso a datos empresariales y lógica en una sola. No es adecuado para todas las soluciones, pero funciona perfectamente para muchos de ellos. Algunas personas pueden incluso combinar Presentación con Business ... que es un importante no no en muchos círculos, pero, de nuevo, puede ser perfecto para la necesidad de que se trate.

Básicamente, el problema que se está resolviendo debe dictar la estructura de la aplicación. Si otras aplicaciones necesitan integrarse con los suyos, a continuación, puede ser necesario añadir una capa de servicio. Esto podría tomar la forma de formularios web simples que otros pueden publicar datos o podría ir más lejos de ser completa en servicios web. Incluso podría haber situaciones en las que desea la capa de servicio sea el camino principal a la localización para múltiples presentaciones.

Usted puede conseguir tan complicado como usted quiera, pero una regla de buena práctica es que sea sencillo hasta las complicaciones se hacen necesarios.

En algunos diseños, la capa de servicio no se usa por la capa de presentación.

La capa de servicio es llamado por otras aplicaciones que quieran utilizar las capas de negocio y acceso a datos en la aplicación.

En cierto modo, la capa de servicio es otro front-end separada de la capa de presentación.

Vea la arquitectónica diagrama aquí. Los usuarios acceden a la aplicación a través de la capa de presentación. Y los sistemas externos acceder a la aplicación a través de la capa de servicios. La capa de presentación y la charla capa de servicios a la fachada aplicación en la capa de negocio.

Como un ejemplo de lo que esos otros "sistemas externos" podrían ser, servicios web y servicios de WCF llame a la capa de servicio. Alguna otra aplicación web podría llamar capa de servicio de esta aplicación en una llamada de servicio web. Esta sería una forma de asegurar que ambas aplicaciones están aplicando la misma lógica de negocio, y que los cambios realizados en la lógica de negocio se refleja en las dos aplicaciones.

Como Chris puntos animados, uno no debe dejarse llevar por la creación de capas. Yo recomendaría solamente la creación de las capas que podrían ser útiles en su aplicación. En mi experiencia, la necesidad de una capa de servicio no es frecuente, pero la necesidad de una capa de negocio es muy frecuente.

La capa de servicios se construye generalmente en términos de operaciones discretas que tienen que ser apoyado por un cliente.

Por ejemplo, una capa de servicio puede exponer Creación de una cuenta. Mientras que la capa de negocio puede consistir en la validación de los parámetros necesarios en la creación de una cuenta, la construcción de los objetos de datos que se persistido, etc.

A menudo, la capa de servicio utiliza un código de procedimiento o estilo de escritura de transacción para organizar las capas de lógica de negocio y / o.

Sabiendo esto, es posible darse cuenta de que su Negocios Capa realmente es una capa de servicio también. En algún momento, el punto desde el que se está haciendo esta pregunta es uno de esos puntos, la distinción es sobre todo semántica.

Desde mi punto de vista una capa de servicio le permite aislar la capa de presentación de su capa de negocio, de la misma forma la capa de acceso de datos de negocios y lo aísla de cómo persisten los datos.

Dentro de la capa de negocio que pondría las cosas que son cruciales para su 'negocio'. Un creada (y probablemente mal concebido ejemplo) sería tener que ser el lugar donde dicen que el descuento de los precios de un producto ocurren.

La capa de servicio le permite separados aún más la interfaz de la empresa. O incluso fuera de intercambio otras capas de negocio en función de los escenarios cambiantes del negocio.

No todas las aplicaciones necesitan uno, aunque (una gran cantidad de variables que entran en la determinación), demasiada arquitectura puede introducir complejidades su equipo puede que no necesite.

Tenga una mirada a lo que dice acerca de Randy Stafford capa de servicios en el "P de EAA" libro http://martinfowler.com/eaaCatalog/serviceLayer.html

  

Capa A de servicio define una   límite de aplicación [Cockburn plop]   y su conjunto de operaciones disponibles   desde la perspectiva de la interconexión   capas de cliente. encapsula la   de la lógica empresarial de la aplicación   control de las transacciones y   respuestas en el coor-dinación   aplicación de sus operaciones.

simple. Para exponer su lógica de negocio a un cliente, utilice una capa de servicio. Pregúntese lo siguiente:

Cuando se cambia la lógica de negocio, si el cambio de capa de servicio? Si la respuesta es "no siempre", entonces se necesita una capa de servicio.

Sé que este hilo es viejo, pero una cosa útil que he hecho en la capa de servicio es a las transacciones mango (Capa de negocios no debe necesitar saber cómo manejar las reversiones, ordenamiento de las operaciones, etc.).

Otra cosa que he hecho es utilizado para traducir entre las entidades de dominio y dtos. Las ofertas de la capa de negocios con el modelo de dominio, pero me han pasado la parte trasera de datos a la capa de presentación en forma de DTO (en algunos casos no era práctico para exponer todo el modelo de dominio para la capa de presentación, por diversas razones), por lo que la capa de servicio se encarga de esta asignación.

En última instancia, veo la capa de negocio a medida que más de grano fino, mientras que la capa de servicio puede ser más grueso en que podría llamar a múltiples operaciones en el BLL, llamadas de orden dentro de una llamada de servicio.

Sí, y yo también la nota en la que la capa de servicio es un lugar bueno para la autenticación, tanto en papel y en base a base de usuario.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top