interfaz de usuario, capa de lógica de negocios, capa de datos y dónde poner servicios web

Question

Estamos desarrollando una aplicación web. Queremos posiblemente reutilizar el trabajo que hacemos aquí para una aplicación diferente que usará la misma base de datos, y usar las mismas reglas de negocio para leer y escribir en dicha base de datos.

Qué diseño sería más correcto

1. Contar con los servicios web de llamada de interfaz de usuario, que utilizaría los objetos de negocio que contienen la lógica de negocio, lo que hablar con la capa de acceso a datos.

2. Hacer que los objetos de negocio de uso de la interfaz de usuario que contienen la lógica de negocio, lo que llamar a los servicios web, que luego hablar con la capa de acceso a datos.

3. Hacer que los objetos de negocio de usuario de interfaz de usuario que contienen la lógica de negocio, lo que hablar con la capa de acceso a datos.

Answer 1

Según su descripción, no ha proporcionado una razón por la que necesitaría el uso de una capa de servicio web. Suponiendo que su sistema de IU pueda acceder a su base de datos, es decir, dentro de la misma red detrás de su cortafuegos, una capa básica de objetos de negocios que el código de UI de su sitio web (supongo que del lado del servidor) utilizará cumple sus requisitos.

Llevar en un nivel de servicio web cuando la distancia entre el sistema de interfaz de usuario y la capa de datos comienza a cruzar los límites que una capa de acceso de datos o la capa de lógica de negocios comenzaría a tener dificultades.

Answer 2

En términos de ser el diseño "correcta" o no, en realidad no es posible dar una respuesta 100% de la corrección de un diseño sin el contexto completo. ¿Cuáles son los requisitos (funcionales y no funcionales)? ¿Qué objetivos de diseño quieres cumplir? ¿Qué tan importante es cada objetivo?

El único objetivo pregunta menciona es que desea volver a utilizar la lógica de negocio con otra aplicación. Cuando quiero reutilizar la lógica comercial de una aplicación de forma estándar, elijo servicios web. Por lo tanto, basándome únicamente en su único requisito, diría que la opción 1 (UI-> Servicio web-> Capa comercial-> Capa de datos) es una buena opción.

Answer 3

Pagar: http://www.icemanind.com/layergen.aspx

La forma en que debe ir es, usted tiene su capa de interfaz de usuario en la parte superior, la capa de datos en la parte inferior y la capa de negocio entre los dos. Cada capa solo puede comunicarse con la capa debajo de ella. Entonces, la interfaz de usuario solo habla de la capa de negocios ... la capa de negocios solo habla con la capa de datos. Su IU nunca debería hablar con la capa de datos y su capa de datos nunca debería interactuar con su UI.

A menos que tenga un motivo para usar un servicio web, entonces no lo haría.

Answer 4

Yo diría que el tercero. Tiendo a pensar en los servicios web como otra capa de presentación.

Piénselo de esta manera: tiene una interfaz de usuario web, que llama al código de su capa empresarial para hacer cosas como crear un nuevo usuario (User.Add), encontrar todos los productos que coincidan con una descripción determinada (Products.FindByDescription), etc.

ahora puede volver a utilizar el mismo código de la capa de negocio para construir un conjunto de servicios web públicas de 3 partes a hacer uso de. Puede haber un método que agrega un usuario, que llama a su método interno User.Add(), otro para encontrar productos, etc.

Lo que obtienes es un conjunto paralelo de presentaciones/interfaces con los mismos datos subyacentes y lógica de negocios.

Detrás de escena (totalmente fuera del alcance de los servicios web o las capas de IU), la capa empresarial llama a una capa de acceso a datos que se encarga de consultar físicamente la base de datos. Si tuviera que cambiar a un DBMS diferente, lo ideal sería (y en teoría) poder reconstruir la capa de datos para la nueva base de datos y hacer que todo simplemente funcione.

La capa empresarial contiene las reglas, como un nombre de usuario que tiene que tener entre 4 y 15 caracteres; los usuarios solo pueden buscar y cargar productos que están en una tienda a la que tienen acceso; etc.

Si decide cambiar una regla comercial, como que un usuario puede buscar productos en cualquier tienda en su estado, la cambia en una sola ubicación y no tiene que tocar el servicio web o UI para que funcione

Answer 5

No mezcle el diseño lógico con el diseño físico. El diseño lógico opera sobre capas y diseño físico - niveles. El servicio web no es una capa. Es simplemente un nivel. En el diseño lógico hay un enfoque estándar: capa UI-> capa BL-> DAL En el diseño físico, todas las capas pueden residir dentro de una aplicación del lado del cliente que conecta la base de datos local o distribuirse en niveles remotos. Pero para las aplicaciones distribuidas generalmente se agrega una capa más: capa de aplicación, que se esconde de la comunicación de la capa BL a través del cable.

Answer 6

Lógicamente, los servicios web pertenecen a la capa de la interfaz de usuario. Piensa que el "Usuario" no solo es un ser humano sino también otro sistema y se vuelve claro. Mantener una separación estricta de las preocupaciones entre estas capas lógicas le permitirá implementar y mantener fácilmente su aplicación.

Answer 7

¿Oye algo acerca de la capa de Servicio? Creo que puede usar una capa de servicio para sus transacciones y operaciones y el uso de una capa de fachada lo ayuda a aislar y administrar el acceso desde la UI a la capa de acceso a datos directa o indirectamente después de visitar la capa Business. depende de tus requisitos