Estratificación

Estratificación

    在分解复杂的软件系统时，软件设计者用的最多的技术之一就是分层。在计算机本身的架构中，可以看到：到处都有分层的例子：不同的层从包含了操作系统调用的程序设计语言，到设备驱动程序和CPU指令集，再到芯片内部的各种逻辑门。网络互联中，FTP层架构在TCP层之上，TCP架构在IP之上，IP又架构在以太网之上。
    当用分层的观点来考虑系统时，可以将各个子系统想象成按照“多层蛋糕”的形式来组织，每一层都依托在其下层之上。在这种组织方式下，上层使用了下层定义的各种服务，而下层对上层一无所知。另外，每一层对自己的上层隐藏其下层的细节。因此，第4层使用第三层的服务，第3层使用第二层的服务，第4层无需知道第二层的细节。（当然，并非所有的分层架构都这么隔绝，但绝大多数是不透明的。）
    将系统按层次分解有很多重要的好处

• Es posible comprender una determinada capa como un todo orgánico sin tener que comprender demasiado otros niveles. Por ejemplo, sin conocer los detalles de funcionamiento de Ethernet, aún puede crear un servicio FTP en TCP.

• La implementación específica de una determinada capa se puede reemplazar, siempre que los servicios prestados antes y después sean los mismos. Por ejemplo, no es necesario cambiar el servicio FTP ya sea en Ethernet, PPP o cualquier red utilizada por el operador de red, y no tiene nada que ver con el operador de red que proporciona el cable de transmisión.

• La dependencia entre niveles se puede minimizar. Suponga que el operador de la red cambia el sistema de transmisión físico, pero mientras la capa de IP siga siendo la misma, el servicio FTP puede permanecer sin cambios.

• La estratificación favorece el trabajo de normalización. TCP e IP son estándares sobre cómo funcionan sus distintos niveles.

• Una vez que se construye un cierto nivel, se puede usar para brindar soporte a muchos servicios de nivel superior. Por lo tanto, FTP, telnet, SSH y HTTP utilizan TCP / IP al mismo tiempo. De lo contrario, todos estos protocolos de alto nivel deben escribir sus respectivos protocolos de bajo nivel.

   分层是一种重要的技术，但也有缺陷：
  

• La jerarquía no encapsula todo. A veces nos trae cambios en cascada. El ejemplo más clásico es en una aplicación empresarial de diseño jerárquico, si desea agregar un campo de datos que se muestra en la interfaz de usuario, debe agregar el campo correspondiente en la base de datos y también debe agregar cada campo entre la interfaz de usuario y la base de datos .Realice los cambios correspondientes a la capa.

• Demasiados niveles afectarán el rendimiento. En cada nivel, generalmente hay una transición de una forma de expresión a otra.

Evolución de niveles en aplicaciones empresariales

El procesamiento por lotes más temprano, archivo único, no requiere jerarquía.
Con la llegada de los sistemas cliente / servidor en la década de 1990, el concepto de capas se hizo más evidente. Dicho sistema es un sistema de dos niveles: el cliente incluye la interfaz de usuario y otros códigos de aplicación, y el servidor suele ser una base de datos relacional. Herramientas de cliente comunes como VB, PowerBuilder y Delphi. Estas herramientas facilitan la creación de aplicaciones con uso intensivo de datos. Porque sus controles de interfaz de usuario suelen ser compatibles con SQL. Por lo tanto, puede arrastrar el control al "área de diseño" para crear una interfaz y luego usar la hoja de propiedades para conectar el control a la base de datos back-end.
Si la aplicación solo incluye una simple visualización y modificación de datos relacionales, entonces este sistema cliente / servidor funciona muy bien. El problema proviene de la lógica del dominio: como reglas de negocio, validación, cálculos, etc. Por lo general, la gente los escribirá en el lado del cliente, pero esto es muy torpe y a menudo incorpora la lógica del dominio directamente en la interfaz de usuario. A medida que la lógica del dominio se vuelva más compleja, estos códigos serán cada vez más difíciles de usar. Además, es fácil generar código redundante de esta manera, lo que significa que cambios simples llevarán a encontrar códigos similares en muchas interfaces.

Otra forma es poner esta lógica en el lado de la base de datos como un procedimiento almacenado. Sin embargo, los procedimientos almacenados solo proporcionan un mecanismo estructurado limitado, que nuevamente conduce a un código torpe. Además, una de las razones por las que a muchas personas les gustan las bases de datos relacionales es que SQL es un estándar que les permite cambiar de proveedor de bases de datos. Debido a que los procedimientos almacenados son privados para el proveedor de la base de datos, el costo adicional de reemplazar al proveedor de la base de datos es demasiado grande.

Mientras que el enfoque cliente / servidor se está volviendo cada vez más popular, el enfoque orientado a objetos está comenzando a aumentar. La orientación a objetos ha encontrado la respuesta al problema de la lógica de dominio: recurrir a un sistema de arquitectura de tres niveles. De esta manera, la interfaz de usuario se implementa en la capa de presentación, la lógica de dominio se implementa en la capa de dominio y los datos se almacenan en la capa de base de datos. Este método le permite extraer lógica de dominio compleja de la interfaz de código, colocarla en la capa intermedia por separado y usar objetos para modelarla y organizarla.