BLL es la Capa de Lógica de Negocio
DAL es la Capa de Acceso a Datos
Arquitectura de tres niveles de ASP.NET (DAL, BLL, UI)
Los gráficos representan una estructura de tres capas. La web es la capa USL
Web –> Bll –> Dal
| | |
| V |
+–> modelo <—+
1. Arquitectura de tres niveles
1. Capa de presentación (USL): Representa principalmente el método WEB, pero también puede expresarse como modo WINFORM. Si la capa lógica es bastante robusta y bien establecida, servirá perfectamente independientemente de cómo se defina y cambie la capa de rendimiento.
2. Capa de lógica de negocio (BLL): principalmente para problemas específicos, también puede entenderse como la operación de la capa de datos y el procesamiento lógico del negocio de datos. Si la capa de datos son los bloques constructores, entonces la capa lógica es el bloque constructor.
3. Capa de acceso a datos (DAL): Es principalmente la capa de operación de los datos originales (en forma de una base de datos, archivo de texto u otra forma de almacenamiento de datos), más que los datos originales, es decir, el funcionamiento de los datos, no la base de datos, específicamente la capa de lógica de negocio o la capa de presentación
Prestación de servicios de datos.
2. Distinción específica
1. Capa de presentación: acepta principalmente la solicitud del usuario y devuelve datos, proporcionando al cliente acceso a la aplicación.
2. Capa de lógica de negocio: principalmente responsable del funcionamiento de la capa de datos, es decir, la combinación de algunas operaciones de la capa de datos.
3. Capa de acceso a datos: Depende principalmente de si tu capa de datos contiene procesamiento lógico; de hecho, sus funciones completan diversas operaciones en el archivo de datos y no tienen que preocuparse por otras operaciones.
3. Resumen
La estructura de tres capas es un enfoque jerárquico estricto, es decir, la capa de acceso a datos (DAL) solo puede ser accedida por la capa de lógica de negocio (BLL), y la capa de lógica de negocio solo puede ser accedida por la capa de presentación (USL). Algunas estructuras de tres capas también añaden otras capas como Factory y Model, que en realidad son una extensión y aplicación sobre la base de estas tres capas.
Un programa sencillo de tres capas generalmente incluye varios proyectos del Modelo Web DAL BLL, y sus referencias mutuas son las siguientes
1) Referencias WEB BLL, Modelo
2) BLL hace referencia a DAL, modelo
3) Referencia DAL Modelo
4) El modelo no tiene citas
En cuanto a la arquitectura de tres niveles, todo el mundo sabe que es la capa de rendimiento (UI), la capa de lógica de negocio (BLL) y la capa de acceso a datos (DAL), y hay muchas formas de subdividir cada capa. Pero cómo escribir el código específico y en qué capa se cuentan esos archivos es vago. El siguiente es un ejemplo sencillo para llevarte a practicar un proyecto de arquitectura de tres capas; este ejemplo tiene solo una función, que es la gestión sencilla de los usuarios.
Primero, crea una solución en blanco y añade los siguientes elementos y archivos
1. Añadir un proyecto de ASP.NET aplicación web, nombrarle UI y crear un nuevo archivo de Formularios Web User.aspx (incluyendo User.aspx.cs)
2. Añadir un proyecto ClassLibrary, llamarlo BLL y crear un nuevo archivo de clase UserBLL.cs
3. Añadir un proyecto ClassLibrary, llamarlo DAL y crear un nuevo archivo de Clase UserDAL.cs. Añade una referencia SQLHelper. (Esta es la clase de acceso a datos de Microsoft, o puedes escribir todo el código de acceso directamente a los datos.) Normalmente uso la clase DataAccessHelper que escribo).
4. Añadir un proyecto Biblioteca de Clases, llamarlo Modelo y crear un nuevo archivo tipo Clase UserModel.cs
5. Añadir un proyecto ClassLibrary, llamarlo IDAL y crear un nuevo archivo de Interface IUserDAL.cs
6. Añadir un proyecto ClassLibrary y llamarlo ClassFactory
Creo que habéis visto que esto no es diferente del ejemplo de Petshop, y es más sencillo, porque también aprendo la arquitectura de tres capas a través de Petshop. Sin embargo, algunos amigos pueden ser vagos sobre el nivel de estos proyectos y la relación entre ellos; aquí va una explicación de cada uno:
1. User.aspx y User.aspx.cs
Ambos documentos (y los elementos a los que pertenece el archivo, así como los que aparecen a continuación, no se repetirán) forman parte de la capa de presentación. User.aspx es más fácil de entender porque es una página de visualización. User.aspx.cs algunas personas piensan que no debería contarse, sino que debería incluirse en la capa de lógica de negocio. Si no haces capas, no hay problema en dejar que User.aspx.cs manejes la lógica de negocio e incluso operar la base de datos, pero si haces capas, esto no debería hacerse. En una estructura jerárquica, User.aspx.cs solo debería tratar contenido relacionado con la visualización, y no debería cubrirse nada más.
Por ejemplo, si implementamos la función de mostrar a los usuarios en forma de lista, entonces el trabajo de extracción de información lo realiza BLL, y después de que la interfaz (en este caso, es User.aspx.cs) llame a BLL para obtener UserInfo, queda vinculada al control de datos de la User.aspx mediante código para realizar la visualización de la lista. En este proceso, User.aspx.cs no juega un papel en la interfaz, solo se usa para pasar datos, y como la mayor parte de la programación se implementa así, algunas personas consideran que User.aspx.cs no debería contarse como interfaz, sino que debería fusionarse con BLL para el procesamiento lógico. Al mirar más allá, se propuso un nuevo requisito para añadir un icono delante de cada usuario que representara vívidamente su género, y para los menores de 18 años, se representaba con un icono infantil. La realización de este requisito es el giro de User.aspx.cs, y en este caso User.aspx.cs tiene un uso real.
2、NewBLL.cs
Añade los siguientes métodos:
GetUsers() de IList público (): Devuelve una lista de toda la información del usuario
public UserInfo GetUser(int UserId): Devuelve los datos del usuario especificado
public bool AddUser(UserInfo User): Información añadida del usuario
public bool ChangeUser(UserInfoUser): Actualiza la información del usuario
empty public RemoveUser(int UserId): Elimina información de usuario
Este archivo pertenece a la capa de lógica de negocio y está dedicado a gestionar operaciones relacionadas con la lógica de negocio. Mucha gente puede pensar que el único uso de esta capa es reenviar los datos de la capa de rendimiento a la capa de datos. De hecho, existen muchos casos así, pero esto solo puede significar que el proyecto es relativamente sencillo, o que la relación entre el propio proyecto y el negocio no está estrechamente integrada (como ocurre con el actual popular MIS), por lo que la capa de negocio no tiene nada que ver y solo desempeña un papel de reenvío. Pero esto no significa que la capa de negocio sea prescindible; a medida que el proyecto crece o hay más relaciones comerciales, la capa de negocio reflejará su papel.
El error más probable aquí es asignar el código de operación de datos a la capa de lógica de negocio y la base de datos como capa de acceso a datos.
Por ejemplo, algunos amigos piensan que la capa BLL no es significativa, pero simplemente suben los datos DAL y los envían a la interfaz sin ningún proceso. Echa un vistazo a este ejemplo
Capa BLL
SelectUser(UserInfo userInfo) obtiene los datos del usuario en función del nombre de usuario o correo electrónico que recibe.
IsExist(UserInfo userInfo) determina si existe el nombre de usuario o correo electrónico especificado.
Entonces el DAL también proporciona el método correspondiente para la llamada BLL
SelectUser(UserInfo userInfo)
IsExist(UserInfo userInfo)
De este modo, BLL solo cumple un papel de transmisión.
Pero si lo haces:
BLL. IsExist(Userinfo de usuario)
{
Usuario UerInfo = DAL. SelectUser(Usuario);
return (userInfo.Id != nulo);
}
Entonces DAL no necesita implementar el método IsExist(), y hay código lógico de procesamiento en BLL.
3、UserModel.cs
Entidad, esta cosa, puede que pienses que no es fácil de estratificar. Incluyéndome a mí, lo entendí así: UI?àModel?àBLL?áModel?àDAL, así que se cree que el Modelo actúa como un puente para la transmisión de datos entre las capas. Pero aquí no pensamos en cosas simples, sino en complejidad.
¿Qué es Model? ¡No es nada! Es prescindible en una arquitectura de tres niveles. En realidad, es lo más básico en la programación orientada a objetos: las clases. Una tabla es una clase, una noticia también es una clase, int, string, doublie, etc. también son clases, es solo una clase.
De este modo, la posición del modelo en la arquitectura de tres capas es la misma que el estado de variables como int y cadena, y no tiene otro propósito; solo se utiliza para almacenamiento de datos, pero almacena datos complejos. Por lo tanto, si los objetos de tu proyecto son muy simples, puedes pasar directamente varios parámetros sin modelo para crear una arquitectura de tres capas.
Entonces, ¿por qué necesitas un modelo y cuáles son sus beneficios? Lo siguiente es lo que viene a la mente al pensar en una pregunta, insertado aquí:
¿Puede el Modelo desempeñar un papel más importante en la transmisión de parámetros en cada capa?
Al pasar parámetros entre capas, puedes hacer lo siguiente:
AddUser(userId,userName,userPassword,...,)
También puede ser así:
AddUser(userInfo)
¿Cuál de estos dos métodos es mejor? A simple vista, debe de ser la segunda mucho mejor.
¿Cuándo pasar parámetros entre capas con tipos normales de variables (int, string, guid, double) y qué pasar con Model? Los siguientes métodos:
SelectUser(int UserId)
SelectUserByName(string username)
SelectUserByName(nombre de usuario en cadena, contraseña en cadena)
SelectUserByEmail (cadena de email)
SelectUserByEmail(correo electrónico en cadena, contraseña en cadena)
Se puede resumir así:
SelectUser(userId)
SelectUser(usuario)
Aquí usamos el objeto modelo de usuario para incluir cuatro modos combinados: nombre de usuario, contraseña y correo electrónico. UserId también puede fusionarse con user, pero otros BLL en el proyecto implementan interfaces con parámetros id, por lo que este elemento también se conserva.
userInfo se pasa, así que cómo manejarlo, esto debe estar en orden de orden, hay un código específico que decidir.
Aquí se procesa en este orden
Primero, comprueba si tienes tanto nombre de usuario como contraseña, luego si tienes correo electrónico y contraseña, después si tienes nombre de usuario y finalmente si tienes correo electrónico. Procesado secuencialmente.
De este modo, si en el futuro se añade un nuevo contenido, la tarjeta de membresía (número), no es necesario cambiar la interfaz, solo añadir soporte para el número en el código DAL y luego añadir el rendimiento y procesamiento del contenido de la tarjeta de membresía en primer plano.
4、UserDAL.cs
SelectUsers() de IList público devuelve una lista de toda la información de los usuarios
public UserInfo SelectUser(int UserId): Devuelve la información confiable del usuario especificado
public bool InsertUser(UserInfoUser): Información añadida del usuario
public bool UpdateUser(UserInfo User): Actualiza la información del usuario
empty public void DeleteUser(int UserId): Elimina información del usuario
Lo que mucha gente no consigue entender es la capa de acceso a datos, ¿qué parte se considera capa de acceso a datos? Algunas personas piensan que la base de datos es la capa de acceso a datos, lo cual no está claro en la definición; DAL es la capa de acceso a datos en lugar de la capa de almacenamiento de datos, por lo que la base de datos no puede ser esta capa. El papel de SQLHelper es reducir la codificación repetitiva y mejorar la eficiencia de la codificación, así que si estoy acostumbrado a preocuparme por la eficiencia o a usar una fuente de datos que no es de base de datos, puedo descartar SQLHelper, una pieza que se puede descartar a voluntad, ¿cómo puede convertirse en una capa de la arquitectura de tres capas?
Se puede definir de la siguiente manera: el código relacionado con las operaciones de la fuente de datos debe colocarse en la capa de acceso a datos, que pertenece a la capa de acceso a datos
5、IUserDAL
Interfaz de capa de acceso a datos, esto es otra cosa prescindible, porque Petshop la trae junto con ClassFactory factory, así que algunos proyectos hacen estas dos cosas independientemente de si necesitan soportar múltiples fuentes de datos o no, y algunos incluso no construyen ClassFactory sino solo IDAL, y luego "IUserDAL iUserDal = new UserDAL(); No sé qué significa. Esto es completamente un tigre y no un anti-perro.
Mucha gente tiene la idea errónea de que existe tal relación: BLL?àIDAL?àDAL, pensando que IDAL actúa como un puente entre BLL y DAL, y BLL llama a DAL a través de IDAL. Pero la realidad es que, incluso si lo codificas así: "IUserDAL iUserDal = ClassFacotry.CreateUserDAL(); Al ejecutar "iUserDal.SelectUsers()", en realidad es la instancia UserDAL la que se ejecuta, no la instancia IUserDAL, por lo que la posición de IDAL en la tercera capa está relacionada con el nivel DAL.
A través de la introducción anterior, básicamente se explica la jerarquía de la arquitectura de tres niveles. De hecho, tengo una forma de juzgar si la arquitectura de tres capas es estándar, es decir, si reemplazar completamente cualquiera de las tres capas no afectará a las otras dos, y que tal estructura básicamente cumple con el estándar de tres capas (aunque es más difícil ^_^ de implementar). Por ejemplo, si cambias el proyecto de B/S a C/S (o viceversa), entonces BLL y DAL no necesitan cambiarse excepto la interfaz; O cambiar SQLServer a Oracle, simplemente reemplazar SQLServerDAL por OracleDAL, no se requieren otras operaciones, etc. Originalmente quería añadir un código específico al artículo, pero no creo que sea necesario; si tú lo crees necesario, lo añadiré.
Resumen: No pienses que una capa es innecesaria solo porque te resulta inútil, o porque sea especialmente sencilla de implementar, o abandonarla, o usarla para otros fines. Mientras las capas se lleven a cabo, sin importar cuántas capas haya, cada capa debe tener un propósito y función claros, y no debe verse influenciada por el proceso real, lo que resulta en que el mismo tipo de archivo esté ubicado en capas diferentes. No dejes que la misma capa implemente funciones diferentes. |
Publicado en 7/5/2015 10:53:35
|
|
|
