Siempre he querido hacer un resumen más completo y perfecto. Pero pensándolo una y otra vez, no sabía cómo empezar. Se dice que empezar es lo más difícil. Hoy he ordenado un poco mis desordenadas ideas, ay, todavía no están bien ordenadas, escribiré según lo que se me ocurra.
Los principiantes no lo entienden bien:
- 1, ¿Qué son las tres capas?
- 2, ¿Por qué usar tres capas?
- 3, ¿En qué se diferencian las tres capas de las dos capas que se usaban antes? ¿Dónde están sus ventajas?
- 4, ¿Cómo aprender bien las tres capas? ¿Cómo aplicar las tres capas? ……
En este blog os lo explicaré una por una. Solo tengo un conocimiento superficial, ¡¡¡espero que me disculpéis!!!
El profesor Mi siempre enfatiza: combinar el estudio con la vida, conectar el estudio con la vida; solo así se puede decir que se sabe estudiar y se sabe vivir.
Para las tres capas, pensé mucho en cómo relacionarlas con la realidad. Bueno, anoche de repente tuve una "inspiración". ¿Recuerdan la historia del capítulo de "Dahua Design Patterns" sobre el Gran Pájaro y Xiao Cai comiendo brochetas de cordero? —que llevó al patrón de comando por pasar de comer en un puesto callejero a comer en un restaurante (por supuesto, hoy no estudiamos el patrón de comando). El camarero, el cocinero y el comprador.
¿Esto no es acaso una típica arquitectura de tres capas? (⊙ o ⊙) ¡Ah! Jaja (esto lo explicaré más adelante)
Primero comprendamos:
1, ¿Qué son las tres capas?
UI (capa de presentación):Se refiere principalmente a la interfaz que interactúa con el usuario. Se utiliza para recibir los datos introducidos por el usuario y mostrar los datos procesados que el usuario necesita.
BLL (capa de lógica de negocio):Es el puente entre la capa UI y la capa DAL. Implementa la lógica de negocio. La lógica de negocio incluye específicamente: validación, cálculo, reglas de negocio, etc.
DAL (capa de acceso a datos):Se encarga de tratar con la base de datos. Principalmente implementa el alta, baja, modificación y consulta de datos. Envía los datos almacenados en la base de datos a la capa de negocio y guarda en la base de datos los datos procesados por la capa de negocio. (Por supuesto, estas operaciones se basan en la capa UI. Las necesidades del usuario se reflejan en la interfaz (UI), la UI se las transmite a BLL, BLL a DAL, DAL realiza las operaciones de datos y, después de operar, las devuelve una a una hasta que los datos requeridos por el usuario se devuelven al usuario).
Cada capa cumple su propia función, entonces, ¿cómo conectar las tres capas?
1, Referencia unidireccional (ver imagen siguiente)
2, Entonces aparece la capa de entidades (Entity). (Nota: por supuesto, las funciones de la capa de entidades no son solo estas).
Entity (capa de entidades):No pertenece a ninguna de las tres capas, pero es una capa indispensable.
El papel de Entity en la arquitectura de tres capas:
- 1, Implementa la "encapsulación" del pensamiento orientado a objetos.
- 2, Atraviesa las tres capas y transmite datos entre ellas; (Nota: en realidad, la capa de entidades atraviesa las tres capas para conectarlas).
- 3, Para los principiantes, se puede entender así: cada tabla de datos corresponde a una entidad, es decir, cada campo de cada tabla de datos corresponde a una propiedad de la entidad. (Nota: por supuesto, en realidad no es así. ¿Por qué? 1> puede que la entidad que necesitamos no exista en la entidad correspondiente a la tabla de datos; 2> podemos perfectamente poner todos los campos de todas las tablas de datos en una sola entidad).
- 4, La transmisión de datos (unidireccional) entre cada capa (UI—>BLL—>DAL) se realiza mediante variables o entidades como parámetros, construyendo así la conexión entre las tres capas y completando la implementación de las funciones.
Pero para grandes cantidades de datos, usar variables como parámetros resulta algo complicado, porque hay demasiados parámetros y es fácil confundirse. Por ejemplo: si quiero pasar la información del empleado a la capa inferior, la información incluye: número de empleado, nombre, edad, sexo, salario... Si se usan variables como parámetros, entonces habrá muchos parámetros en nuestro método, y es muy probable que al usarlos se confunda la correspondencia de los parámetros. En ese momento, si se usa una entidad como parámetro, será muy conveniente; no hay que preocuparse por la correspondencia de parámetros, solo se toma directamente la propiedad de la entidad que se necesite. Es muy cómodo y además mejora la eficiencia.
（Nota:¿Por qué aquí se dice que temporalmente se puede entender que cada tabla de datos corresponde a una entidad? Respuesta: todos sabemos que el propósito de hacer un sistema es proporcionar servicios a los usuarios. A los usuarios no les importa cómo funciona el backend de tu sistema; solo les importa si el software es fácil de usar y si la interfaz se ajusta a sus gustos. Cuando el usuario realiza fácilmente altas, bajas, modificaciones y consultas en la interfaz, la base de datos también debe tener las correspondientes altas, bajas, modificaciones y consultas. Y el objeto concreto de esas operaciones son los datos de la base de datos, en otras palabras, los campos de las tablas. Por lo tanto, si se trata cada tabla de datos como una clase de entidad, y las propiedades encapsuladas por la clase de entidad corresponden a los campos de la tabla, entonces, cuando la entidad atraviesa las tres capas, se pueden implementar las operaciones de alta, baja, modificación y consulta de datos.
En resumen: la relación de dependencia entre las tres capas y la capa de entidades:
La idea proviene de la vida:
Camarero:Solo se encarga de atender a los clientes.
Cocinero:Solo se encarga de preparar los platos que pide el cliente.
Comprador:Solo se encarga de comprar los ingredientes según lo que pide el cliente.
Cada uno cumple su función. El camarero no necesita saber cómo cocina el cocinero ni cómo compra los ingredientes el comprador; el cocinero no necesita saber a qué cliente atendió el camarero ni cómo compra los ingredientes el comprador; de igual manera, el comprador no necesita saber a qué cliente atendió el camarero ni cómo cocina el cocinero.
¿Cómo se relacionan los tres?
Por ejemplo: el cocinero sabe hacer: berenjena salteada, huevos revueltos y fideos salteados — en este caso se construyen tres métodos (cookEggplant(), cookEgg(), cookNoodle()).
El cliente trata directamente con el camarero. El cliente le dice al camarero (capa UI): quiero una berenjena salteada. Como el camarero no es el responsable de saltear la berenjena, envía la solicitud hacia arriba, se la transmite al cocinero (capa BLL). El cocinero necesita berenjena, así que envía la solicitud hacia arriba, se la transmite al comprador (capa DAL). El comprador trae la berenjena del almacén y se la devuelve al cocinero; el cocinero responde al método cookEggplant(), prepara la berenjena salteada y se la devuelve al camarero; el camarero se la presenta al cliente.
Así se completa una operación completa.
En este proceso, la berenjena se transmite como parámetro a través de las tres capas. Si el cliente pide huevos revueltos, entonces el huevo se usa como parámetro (aquí se utilizan variables como parámetros). Si el usuario añade requisitos, tenemos que agregar parámetros en los métodos; un método agrega uno, y un método involucra a las tres capas; y en la práctica no se trata solo de modificar un método. Por lo tanto, para resolver este problema, podemos definir la berenjena, el huevo y los fideos como propiedades en la entidad Cliente. Una vez que el cliente añade el requisito de huevos revueltos, basta con tomar directamente la propiedad del huevo y usarla; ya no hay que considerar agregar parámetros en los métodos de cada capa, y mucho menos el problema de la correspondencia de parámetros.
Explicado así, no sé si todos lo podrán entender. (Más tarde lo explicaré con un ejemplo).
2, ¿Por qué usar tres capas?
El propósito de usar la arquitectura de tres capas: ¡¡¡desacoplar!!!
Tomemos de nuevo el ejemplo del restaurante de arriba:
(1) El camarero (capa UI) pide permiso: se busca otro camarero; el cocinero (capa BLL) renuncia: se contrata a otro cocinero; el comprador (capa DAL) renuncia: se contrata a otro comprador. (2) Los clientes informan:
- 1, El servicio de su restaurante es malo — es problema del camarero. Despedir al camarero.
- 2, Hay un insecto en el plato de su restaurante — es problema del cocinero. Cambiar de cocinero.
¡¡¡Que cualquier capa cambie no afectará a las otras capas!!!
3, ¿Diferencias con dos capas??
Dos capas:
(Cuando cualquier parte cambia, es necesario rediseñar todo el sistema. Las "múltiples capas" están en una sola capa, la división del trabajo no es clara y el acoplamiento es alto — es difícil adaptarse a los cambios de requisitos, la mantenibilidad es baja y la escalabilidad es baja).
Tres capas:
(Si el cambio ocurre en una capa, solo hay que modificar esa capa, no es necesario modificar todo el sistema. Las capas están claras, la división del trabajo es clara, el acoplamiento entre capas es bajo — mejora la eficiencia, se adapta a los cambios de requisitos, la mantenibilidad es alta y la escalabilidad es alta).
En resumen, las ventajas de la arquitectura de tres capas:
- 1, Estructura clara y bajo acoplamiento
- 2, Alta mantenibilidad y alta escalabilidad
- 3, Favorece la realización simultánea de tareas de desarrollo y es fácil adaptarse a los cambios de requisitos
Ventajas y desventajas de la arquitectura de tres capas:
- 1, Reduce el rendimiento del sistema. Esto es evidente. Si no se adopta una estructura en capas, muchos procesos pueden acceder directamente a la base de datos para obtener los datos correspondientes; ahora, en cambio, tienen que pasar por la capa intermedia.
- 2, A veces provoca modificaciones en cascada. Esta modificación se refleja especialmente en la dirección de arriba hacia abajo. Si en la capa de presentación se necesita agregar una función, para garantizar que su diseño cumpla con la estructura en capas, es posible que sea necesario agregar el código correspondiente tanto en la capa de lógica de negocio como en la capa de acceso a datos.
- 3, Aumenta la cantidad de código y aumenta la carga de trabajo.
4, ¿Formas de manifestación concretas de las tres capas??
UI：
(No lo malinterpreten: la capa UI no es solo la interfaz de usuario, también necesita código).
(1, Función: el usuario introduce datos y se devuelven datos al usuario; 2, observen el código: no involucra lógica de negocio, solo transmisión de parámetros, llamadas a funciones y métodos; no involucra sentencias SQL ni ADO.NET para tratar con la base de datos).
BLL：
(1, BLL es el puente entre la capa de presentación y la capa de acceso a datos; se encarga del procesamiento y la transmisión de datos; 2, observen el código: no involucra controles de la interfaz, ni sentencias SQL ni ADO.NET).
DAL：
(1, Lo anterior es el código de las clases DbUtil, user_DA y workRecord_DA en la capa DAL; 2, observen el código: no involucra controles de interfaz ni lógica de negocio; solo sentencias SQL y ADO.NET para tratar con la base de datos).
Capa Entity (Model):
(Define la clase de entidad user).
Observando las tres capas anteriores:
- 1, La clase de entidad user se transmite como parámetro a través de las tres capas.
- 2. Implementar la funcionalidad mediante el paso de parámetros y llamadas a métodos;
- 3. Cada capa se encarga de sus propias responsabilidades; no se afectan entre sí.
Comparando con la estructura de dos capas, permítanme apreciar profundamente las enormes ventajas de las tres capas:
Tomemos como ejemplo el inicio de sesión del sistema de cobro de la sala de computadoras:
(Observando el código de las dos capas anterior: tanto la lógica de negocio como el acceso a datos se muestran en la capa de presentación de usuario. Cuando los requisitos necesitan cambiar, hay que cambiar todo el sistema. Por ejemplo, si cambio el nombre del cuadro de texto txtPassWord a txtPwd, observen cuántos lugares habría que modificar. Este tipo de cambio se considera pequeño; si realmente hubiera cambios en los requisitos de negocio, sería complicado y problemático. Sería un milagro que el programador no saltara por la ventana. Jeje... es una broma.)
Dirección original: https://blog.csdn.net/hanxuemin12345/article/details/8544957/