¿Es ineficaz una arquitectura de nivel 3 (física)?

Question

Nota: Cuando me refiero a un nivel, me refiero a un nivel físico. Muchas de las preguntas en este sitio relacionadas con "niveles" se refieren a capas lógicas, que no es lo que estoy preguntando.

Estoy diseñando una aplicación que utiliza una arquitectura estándar de "3 capas", con capas de presentación, lógica comercial (BLL) y acceso a datos (DAL). La tecnología es WPF, C#, LINQ y SQL Server 2008. Mi pregunta se relaciona con la arquitectura física de esta aplicación.

Puedo colocar el BLL/DAL en una DLL estándar que se carga y ejecuta en la máquina del usuario, creando una arquitectura de 2 niveles: máquina cliente y servidor de base de datos. Pero no es demasiado difícil convertir el BLL/DAL en un servicio WCF que se encuentra en un servidor de aplicaciones y se llama desde la máquina del usuario. Esto me daría una arquitectura de 3 niveles: máquina cliente, servidor de aplicaciones y servidor de base de datos.

Mi pregunta es esta: ¿cuál es la ventaja de usar una arquitectura de 3 niveles? A menudo me han dicho que 3 niveles agregan escalabilidad, pero no es inmediatamente evidente para mí por qué sería esto. Y seguramente tendrá un éxito de rendimiento con los mismos datos teniendo que hacer dos saltos por cable, desde el servidor de la base de datos al servidor de la aplicación, luego desde el servidor de la aplicación al equipo del cliente.

Agradecería el asesoramiento de arquitectos y desarrolladores experimentados.

Answer 1

Depende del uso de su aplicación y sus requisitos de seguridad. Si su aplicación se está utilizando a través de Internet y está almacenando cualquier cosa que sea potencialmente sensible de alguna manera, es muy recomendable agregar la eliminación física para la base de datos. Nunca, nunca deje que nadie desde el exterior en cualquier máquina con acceso directo a su base de datos. Las personas pueden y tratarán de romper su seguridad sin una razón mejor que la que no tienen nada mejor que hacer.

La escalabilidad también puede ser un factor, tanto en frente de la capa de presentación (frente a los servidores web) como en la base de datos. Colocar un equilibrador de carga delante de la capa de presentación permite enrutar las solicitudes entrantes a una matriz de máquinas que se pueden gestionar de forma independiente. Las máquinas se pueden agregar a la piscina en momentos de necesidad y se pueden eliminar para realizar tareas de mantenimiento. Colocar equilibradores de carga entre las otras capas puede tener el mismo impacto. La idea es proporcionar un entorno de back-end flexible y dinámico que se pueda ajustar según lo requiera la demanda.

Answer 2

Puede ser. Depende de lo que se haya implementado y cómo.

La fuerza impulsora para crear una arquitectura física de 3 niveles no está necesariamente relacionada con el rendimiento.

La razón por la escalabilidad se cita es que un servicio podría ejecutarse en una granja de servidores, pero los clientes no estarían conscientes de esto. El tamaño de la granja de servidores se puede aumentar para satisfacer la demanda si la arquitectura se ha diseñado para admitirlo.

Answer 3

La ineficiencia está en el ojo del espectador.

Por ejemplo, tener todo en el cliente puede aumentar la huella de memoria o los requisitos de CPU/red de las computadoras cliente. Si este trabajo se puede descargar a un servidor/granja de servidores, puede ahorrar tener que hacer actualizaciones de hardware de las PC del cliente solo para ejecutar su software. Si se necesitan más recursos o actualizaciones, se pueden agregar/hacer en el nivel lógico de negocios sin afectar a los clientes.

Además, tener la lógica empresarial en su propio nivel puede ser más eficiente más adelante (desde una perspectiva de desarrollo de software) cuando necesita exponer algunas funcionalidades de su aplicación en un sistema basado en web, o un complemento de Outlook, o una aplicación de iPhone.No desea tener que actualizar todos estos sistemas cada vez que la lógica de negocios cambie ligeramente.

La seguridad puede ser mejor, ya que los usuarios no necesitan acceso directo al servidor de la base de datos, están aislados por el servidor de la aplicación.

También lo obliga a pensar en su aplicación de forma modular con interfaces bien definidas que pueden tener ventajas arquitectónicas para el diseño de su aplicación.

Answer 4

Siempre que se pregunte "¿Es X ineficiente?" usted debe, inmediatamente, hágase tres preguntas precursoras:

1. Por "ineficiente", lo que recursos crees que se debe utilizar de manera eficiente y puede no ser? ¿Hora? ¿Espacio? Ancho de banda? horas de desarrollo?

2. ¿Por qué te importa? No, en serio: si vas a pasar incluso un minuto respondiendo esta pregunta, tiene que haber una razón. ¿Cuál es esa razón?

3. Comparado con qué?

En lo que se refiere a su comentario acerca de la escalabilidad: Durante un tiempo, tuve la desafortunada responsabilidad de mantener un sistema cuyo arquitecto que había sido informado de que la minimización viajes redondos a la base de datos sería una aplicación escalable. Él tomó esa idea y corrió con ella. Puede leer sobre este proyecto here. Se me ocurre que debería haber mencionado que en ningún momento durante toda la década o más de la vida útil de esa aplicación hubo más de cuatro usuarios conectados simultáneamente.

Answer 5

La ventaja principal de las aplicaciones 3t descritas como lo hizo no es la escalabilidad. Mantenibilidad tal vez.

Para hacer que su arquitectura sea escalable, necesita una tecnología más que no haya mencionado. - necesita servicios. Sugeriría WCF.

Al hacer que su servicio BLL WCF (o servicios múltiples) haría que su aplicación sea mucho más eficiente y escalable, permitiendo que su BLL se ejecute en diferentes/múltiples máquinas.