varias superponer studio lineas graficos graficas design-patterns architecture n-tier tiers

design patterns - superponer - Diferencia entre tres niveles vs. n niveles



superponer graficas en r (9)

Acabo de encontrar la siguiente frase:

A medida que la industria se ha movido de un modelo de tres niveles a uno de n niveles, el desajuste de la impedancia relacional del objeto se ha vuelto más frecuente.

Pero no puedo encontrar una explicación concisa de la diferencia entre tres niveles y n niveles. Sé cuál es el nivel tres, y supongo que n-tier solo agrega uno o más niveles. No estoy seguro de cuáles serían estos niveles adicionales. Si alguien tiene una breve explicación o simplemente un buen enlace, sería muy apreciado.

¿De dónde es esa cita? ¿A qué industria se están refiriendo? Tendría que imaginar que esto tiene algo que ver con SOA porque es lo único que tiene sentido para este tipo de afirmación.

La mayoría de las personas que he escuchado que hacen este tipo de afirmaciones creen que, en un dominio orientado a servicios, cada servicio es de alguna manera su propio nivel. No estoy de acuerdo ya que la mayoría de las veces estos servicios dispares pueden agruparse lógicamente en tres niveles comunes (presentación, lógica y datos). Pero, de nuevo, todo es bastante subjetivo.

La cita parece ser de esta página de proyecto de código . También parece hacer un buen trabajo explicando n-tier para incluir cosas como servicios web, javascript, flujos de trabajo, etc. Todo lo que los modelos de 3 niveles no necesariamente incluyen.

Oye, ni siquiera puedo obtener una definición de 3 niveles. A veces descuentan javascript en el cliente y, a veces, el javascript en el cliente y el navegador web del cliente se consideran otro nivel. Así que una página ASP que habla con una base de datos puede ser de 3 niveles si supone database = tier 3, web server = tier 2, client web browser = tier 1. Y otras veces web server = tier 1, middleware = tier 2, database = nivel 3. Realmente depende de quién escriba la definición / libro.

En general, n-tier parece referirse a dividir más la capa de middleware. Pero aparte de eso, no veo definiciones consistentes.

Sin ver la oración en contexto, supongo que se está refiriendo a la explosión en servicios y middleware.

n-tier implica n es cualquier número: cuando n = 3, entonces es lo mismo que n-tier.

La definición usual de 3 niveles es presentación, lógica y datos (en cualquier orden), y sí, SOA puede confundir al neófito porque a veces se ubica en el nivel de datos, a veces el nivel lógico y algunas veces los niveles lógicos y de datos.

Todo el tema es ... subjetivo. Si necesita algunos niveles, llámelo n-tier; si sabe que n = 7, llámelo nivel 7 o n-nivel.

Si miramos los niveles como capas de un pastel; cada capa tendría sus propios ingredientes y haría sus propias cosas. Los niveles de cada aplicación interactúan solo con el nivel superior o inferior.

3 niveles significa que la torta tiene 3 capas. Usualmente son datos en la parte inferior, luego un nivel lógico de aplicación (PHP / ruby ​​/ etc), y luego un nivel de presentación en la parte superior (html)

Tener una arquitectura n-tier significa que diseñas algo con varias capas de capa. La cantidad de capas que tenga dependerá de cómo decida hacerlo.

Parece tener mucho más sentido con aplicaciones más grandes o web.

Por lo general, termino con una aplicación de 5 niveles. Cada nivel solo puede interactuar con el que está arriba o debajo de él. Esto puede proporcionar una excelente extensibilidad y estandarización en su aplicación.

Nivel de cliente

Navegador web

Nivel de presentación

Renderiza el HTML - Coldfusion / Flash / Ruby / PHP, etc.

Nivel de lógica de negocios

Ejecute los procesos y cálculos según sea necesario: Coldfusion / Flash / Ruby / PHP, etc.

Nivel de integración de datos

(Consultas de mi lenguaje de desarrollo, procedimientos almacenados, etc.)

Nivel de datos

(Base de datos - MySQL, etc.)

En desarrollo, entendemos un nivel como una abstracción de " nivel de responsabilidad ".

Tal nivel de responsabilidad agrupa los conceptos para proporcionar una visión semántica coherente de la realidad, o al menos algo similar a la realidad.

En tal sentido, los llamados modelos de 3 niveles o n niveles son simplemente implementaciones diferentes de esos conceptos.

Un buen ejemplo de un nivel sigue el modelo jerárquico donde las responsabilidades se dirigen cuidadosamente a las personas adecuadas. Por ejemplo, un negocio común tiene departamentos de Comercial, Marketing, Sistemas, Desarrollo y Pruebas (por ejemplo), que representan los niveles de negocios. De esta forma, las responsabilidades son claras, el desarrollo proporciona el producto, la prueba lo prueba, el marketing lo promueve y el comercial lo vende, todo mientras los sistemas mantienen la infraestructura en funcionamiento (es solo un ejemplo).

Esta metáfora se abordó por primera vez con el modelo de 3 niveles, donde se identifican tres niveles. Usualmente estos niveles son Capa de abstracción de base de datos , que está a cargo de la comunicación y abstracción sobre la base de datos, Capa de reglas empresariales , que contiene las reglas que describen el proceso de negocios y la Capa de interfaz de usuario que abstrae la interacción del usuario con el sistema.

De esta forma, tenemos roles para las responsabilidades de cada capa, de modo que si el usuario necesita interactuar con el sistema, se comunicará con una capa, sin desordenar el sistema.

N-tier representa una evolución del concepto anterior mediante el uso de más niveles para atender necesidades específicas. Por lo general, la capa de interfaz de usuario y la capa de abstracción de la base de datos no se tocan, ya que sus funciones son bastante claras, mientras que la capa de reglas de negocio se refina aún más.

Para eso, siempre tomamos en cuenta las características del problema, así como las características que queremos ofrecer ahora y en el futuro. Por ejemplo, si una aplicación necesita trabajar con clientes inteligentes o está previsto que trabaje con clientes inteligentes, entonces la capa de negocios generalmente se divide en una capa de proxy y una capa de fondo, la primera enrutar las llamadas a donde deberían ir.

Al final, lo importante es el concepto de abstraer responsabilidades entre las diferentes capas y centralizar todas las operaciones relacionadas desde una vista semántica en el mismo lugar.

Tenga en cuenta que, además, la arquitectura n-tier permite la distribución de esas "responsabilidades" entre los desarrolladores. De esta forma, un equipo determinado puede tener responsabilidad sobre la capa de abstracción de la base de datos mientras que otro equipo trabaja en la capa de proxy y otra funciona en la capa de abstracción de gráficos. Cuando un miembro de un equipo necesita acceder a la base de datos, busca la documentación DAL y utiliza una de las instalaciones proporcionadas o solicita al equipo DAL que proporcione la funcionalidad que necesita, para que no se dirija directamente a la base de datos sino a través de las personas que mejor conoce el diseño y las complejidades de la base de datos en sí.