¿Qué significa n-tier para ti?

Question

He notado a lo largo de los años que diferentes desarrolladores tienen diferentes criterios para lo que constituye un nivel en el desarrollo de un sistema de n niveles, por lo que tenía curiosidad sobre cuál es el consenso aquí en stackoverflow.

¿Son suficientes las capas lógicas separadas para llamarlo un nivel separado o tiene que ser desplegable en un servidor separado (físico o virtual) para llamarlo un nivel separado?

Permítanme formular la pregunta un poco diferente. Si el mecanismo de llamada solo puede estar en proceso, subproceso local o departamento local, ¿es posible afirmar que se trata de dos niveles diferentes dependiendo de cómo se organizan las clases en bibliotecas o paquetes?

Answer 1

Para mí, el nivel físico significa parte del sistema, diseñado para ejecutarse en una máquina física diferente. Sí, puede apuntar su cadena de conexión db a otro servidor en cualquier momento, pero si su DAL es demasiado hablador, tiene n + 1 y problemas de conjunto de registros ilimitados, la latencia de red lo matará realmente rápido.

La capa lógica, por otro lado, soporta virtudes de separación de preocupaciones, cohesión y acoplamiento. Estrictamente, ni siquiera tiene que estar en un ensamblaje separado: el espacio de nombres hará el truco. Simplemente no llame a clases que sabe que no debería, NDepend lo ayudará.

Answer 2

Una capa lógica separada es suficiente para llamarlo un nivel. No necesariamente tiene que estar en un servidor separado, pero la separación definida de otras capas ciertamente lo hace posible.

Como ejemplo, solíamos tener lo que yo llamaría un sistema de 3 niveles (páginas db, dll, asp) ejecutándose en un solo servidor. Según algunas definiciones, este es un sistema de un solo nivel. Ahora tenemos la base de datos ejecutándose en un servidor separado, el único cambio requerido fue una cadena de conexión, ¿pero ahora sería una solución de dos niveles?

Es por eso que siento que el concepto de un nivel se trata más de la capacidad de ejecutarlos en máquinas separadas en lugar de tener que hacerlo. Simplemente me parece más consistente.

Answer 3

  

Los conceptos de capa y nivel son   A menudo se usa indistintamente. Sin embargo,   un punto de vista bastante común es   que de hecho hay una diferencia, y   que una capa es una estructuración lógica   mecanismo para los elementos que hacen   la solución de software, mientras que un nivel   es un mecanismo de estructuración física   para la infraestructura del sistema

Ref. .

Answer 4

Las capas son un mecanismo para minimizar el acoplamiento; Son lógicos. Los niveles están diseñados para maximizar el rendimiento o negar los riesgos de seguridad; Son físicos. Realmente no son los mismos y no estoy seguro de por qué las personas intentan usarlos indistintamente.

La gran mayoría de las aplicaciones web son de 3 niveles por defecto (navegador, servidor web, servidor de bases de datos). La mayoría de las aplicaciones de intranet son de 2 niveles (cliente, servidor de base de datos). Pero en cualquier caso, construyo una capa de interfaz de usuario, una capa de negocios y una capa de datos. Tienen una separación de preocupaciones y me ayudan a estructurar mi código para mantenerlo. También en cualquier caso, generalmente termino desplegándolos a todos en una caja; servidor web o estación de trabajo cliente. Entonces las capas y los niveles ni siquiera coinciden.

Answer 5

Siempre creí que un nivel es cualquier separación física en una arquitectura, es decir, una máquina. Descubrí que estos chicos piensan lo mismo últimamente, es un libro muy bueno.

Pero pensando bien después de leer las otras respuestas, estoy de acuerdo con Garry en eso .

Answer 6

Yo estaría de acuerdo con Garry Shutler pero agregaría que también podrían existir muchos niveles en un solo proceso / subproceso o incluso en el mismo ensamblado. Más importante que la separación física (hardware, aislamiento ejecutable o aislamiento binario) es el diseño del código para el desarrollador (en mi humilde opinión). como en una aplicación aspnet: el mismo dll podría tener los tres niveles: acceso a datos, dominio y presentación.

Answer 7

Tendría que decir que las definiciones deben ser elaboradas. Normalmente pienso en un nivel como una separación lógica de funcionalidad y responsabilidad y una capa como el requisito o la capacidad para una separación física. Algunas capas pueden tener múltiples niveles y algunos niveles pueden abarcar capas. Normalmente uso un nivel de capa de servicio que tiene la capacidad de proporcionar separación física si es necesario y / o deseado a través de la configuración.

Entonces, pregunta / comentario de seguimiento. Si hay un montón de lógica (comercial o de otro tipo) en los procedimientos almacenados en su base de datos, ¿debería eso considerarse también un nivel? ¿Qué sucede si está utilizando características de su motor de base de datos como Service Broker para Microsoft SQL Server? Se puede ver que tiene dos niveles en sí.

Además, los servicios en segundo plano y / o demonios, ¿son un nivel y / o capa separados o pertenecen a uno existente?

Answer 8

Mire el historial del término " tier " en informática. Nadie dijo computación de 1 nivel en computadoras de escritorio / minis / mainframes. Nadie dijo computación de 2 niveles durante los días cliente-servidor. 3 niveles se convirtió en el apodo arquitectónico para el cliente-servidor más el middleware intermedio (middleware orientado a mensajes y corredores de transacciones). Creo que n-tier se popularizó junto con otro término "EAI - o Enterprise Architecture Integration". Era precisamente la misma idea que las arquitecturas orientadas a servicios, excepto que la mayoría de las implementaciones de los proveedores eran propietarias, basadas en estándares pero muy caras, o ambas. Después de que aparecen XML-RPC, SOAP y REST, lo llaman "Servicios web". y luego aplique el principio EAI detrás de él y llegue a SOA - Arquitectura orientada a servicios y Bus de servicios empresariales.

Mi punto es que ninguno de estos términos implicaba separación física ... siempre se trataba de la separación lógica de la funcionalidad. Dio la casualidad de que muchas de estas capas de aplicaciones lógicas fueron diseñadas para no tener estado, de modo que PODRÍAN estar físicamente separadas con el fin de lograr una escalabilidad horizontal.