Explicación detallada de la arquitectura de tres niveles de C#
Este artículo utiliza un ejemplo para presentar cómo construir un proyecto de arquitectura de tres niveles y explica el nivel y la función de cada archivo en el proyecto. El propósito de escribir este artículo no es explicar qué tan correcto es mi método. Lo es, pero espero que brinde algo de ayuda a aquellos amigos que son nuevos en la arquitectura de tres niveles pero no saben por dónde empezar. La mayoría de los artículos en Internet se centran en la introducción teórica e ignoran aplicaciones prácticas específicas. Ejemplos, pero la explicación no es exhaustiva, lo que lleva al estudio teórico después de leer. Pero todavía no sé cómo escribir el código, así que quiero comenzar desde este aspecto y escribirlo para que los principiantes que nunca hayan hecho un tres. La arquitectura de niveles también puede escribir el código de acuerdo con el código. El código del artículo es un pseudocódigo y solo se usa para ilustrar la idea
Text
Cuando se trata de tres. Arquitectura de niveles, todo el mundo sabe que es la capa de presentación (UI), la capa de lógica de negocios (BLL) y la capa de acceso a datos (DAL). Hay muchas formas de subdividir cada capa, pero cómo escribir el código específico y en qué capa están esos archivos. están incluidos aún no están claros. Usemos un ejemplo simple para guiarlo a través de la implementación real de un proyecto de arquitectura de tres niveles. Este ejemplo solo tiene una función, que es la administración simple de usuarios.
Primero cree un. solución en blanco y agregue los siguientes proyectos y archivos
Agregue el proyecto de aplicación web ASP NET y asígnele el nombre UI. Cree un nuevo archivo de tipo formulario web Usuario aspx (incluido Usuario aspx cs)
.
Agregue un proyecto ClassLibrary y asígnele el nombre BLL. Cree un nuevo archivo de tipo Clase UserBLL cs.
Agregue un proyecto ClassLibrary y asígnele el nombre DAL. Cree un nuevo archivo de tipo Clase UserDAL cs. una referencia de SQLHelper (esta es la clase de acceso a datos de Microsoft y no es necesario que la escriba directamente. Cuando escribo todos los códigos de acceso a datos, normalmente uso la clase de acceso a datos DataAccessHelper escrita por mí)
Agregue un proyecto y un nombre de ClassLibrary it Model. Cree un nuevo archivo de tipo Class UserModel cs
Agregue un proyecto ClassLibrary y asígnele el nombre IDAL. Cree un nuevo archivo de tipo Interface IUserDAL cs
Agregue el proyecto ClassLibrary y asígnele el nombre ClassFactory.
Creo que ya has visto que esto no es diferente del ejemplo de Petshop y es más simple porque la arquitectura de tres niveles también se aprende a través de Petshop a continuación. Pero algunos amigos pueden ser vagos acerca de los niveles de estos proyectos. y la relación entre ellos. Déjame explicarlos uno por uno
Usuario aspx y Usuario aspx cs
Estos dos archivos (lo mismo ocurre a continuación para el proyecto al que pertenece el archivo. , así que no lo enfatizaré nuevamente) Todos pertenecen a la parte de la capa de presentación. El usuario aspx es más fácil de entender porque solo muestra la página. Algunas personas piensan que el usuario aspx cs no debe contarse sino incluirse en el negocio. capa lógica. Si no realiza capas, no hay problema en permitir que el usuario aspx cs maneje la lógica empresarial e incluso opere la base de datos. Pero si realiza capas, esto no debería suceder en la estructura jerárquica. solo debe manejar contenido relacionado con la visualización y otras partes no deben estar involucradas.
Por ejemplo, si implementamos la función de mostrar usuarios en una lista, entonces el trabajo de extraer información está terminado. por la interfaz de usuario de BLL (en este caso, Usuario aspx cs). Llame a BLL para obtener la información de usuario y vincularla a través del código. La visualización de la lista se realiza en el control de datos de Usuario aspx. no juega ningún papel en la interfaz de usuario. Solo se usa para transferir datos y porque.
La mayoría de las situaciones en la codificación real se implementan de esta manera, por lo que algunas personas piensan que el usuario aspx cs no debe contarse como UI, sino que debe incorporarse a BLL para ser responsable del procesamiento lógico. Si continuamos leyendo, se propone un nuevo requisito, que. requiere agregar un ícono delante de cada usuario que expresa vívidamente el género del usuario, y se usa un ícono secundario para expresar el género del usuario. En este caso, el usuario aspx cs tiene su turno. propósito real
NewBLL cs
Agrega los siguientes métodos
public IListlt GetUsers() Devuelve una lista de toda la información del usuario
public bool AddUser(UserInfo User) Agregar información del usuario
public bool ChangeUser(UserInfo User) Actualiza la información del usuario
public void RemoveUser( int UserId) Eliminar información del usuario
Este archivo pertenece a la capa de lógica empresarial, que se utiliza especialmente para manejar operaciones relacionadas con la lógica empresarial. Mucha gente puede pensar que es la única. El propósito de esta capa es pasar la capa de presentación. De hecho, hay muchas situaciones en las que los datos se reenvían a la capa de datos, pero esto solo muestra que el proyecto es relativamente simple o que la relación entre el proyecto en sí y el negocio no está estrechamente integrada ( (como el actualmente popular MIS), por lo que la capa empresarial no tiene nada que hacer y solo sirve como reenvío. Pero esto no significa que la capa empresarial sea prescindible A medida que el proyecto crezca o haya más relaciones comerciales, la capa empresarial se reflejará. su función
La causa más probable de error aquí es El código de operación de datos se coloca en la capa de lógica empresarial y la base de datos se utiliza como capa de acceso a datos
Por ejemplo, algunos mis amigos sienten que la capa BLL tiene poca importancia. Simplemente extraen los datos DAL y los reenvían a la interfaz de usuario sin ningún procesamiento. Mire este ejemplo
Capa BLL
. SelectUser (UserInfo userInfo) obtiene detalles del usuario en función del nombre de usuario o correo electrónico entrante
IsExist (UserInfo userInfo) determina la designación Si el nombre de usuario o el correo electrónico existe
Luego, DAL también proporciona el método * **BLL llama en consecuencia
SelectUser (UserInfo userInfo)
IsExist (UserInfo userInfo)
p>
De esta manera, BLL solo reproduce un pasando rol
Pero si haces esto
BLL IsExist (Userinfo userinfo)
{
UerInfo user = DAL SelectUser(Usuario)
return (userInfo Id != null)
}
Entonces DAL no necesita implementar IsExist() Después de este método, también hay código de procesamiento lógico en BLL
UserModel cs
Todos pueden pensar que las clases de entidad no son fáciles de superponer. Así es como entendí la interfaz de usuario antes, incluido yo. De esta forma, se considera que Model juega un papel como puente para la transmisión de datos entre varias capas. Pero aquí no estamos hablando de cosas.
Quiero ser simple, pero quiero ser complicado
¿Qué es Model? ¡No es nada! Es prescindible en la arquitectura de tres niveles. En realidad, es lo más básico en la programación orientada a objetos. Una tabla es una clase, una noticia también es una clase, una cadena int doble, etc., también es una clase. class.
De esta manera, la posición del Modelo en la arquitectura de tres niveles es la misma que la posición de variables como int string. No tiene otro propósito. Solo se usa para el almacenamiento de datos. Solo almacena datos complejos, por lo que si los objetos en su proyecto son muy simples, puede crear una arquitectura de tres niveles pasando directamente múltiples parámetros sin usar el modelo.
Entonces, ¿por qué necesita un modelo? ¿Cuáles son sus beneficios? Estas son las cosas que le vienen a la mente al pensar en un problema e insértelas aquí.
¿Puede el modelo desempeñar un papel más importante al pasar parámetros en cada capa?
Esto se puede hacer al pasar parámetros entre capas
AddUser (userId nombre de usuario contraseña de usuario...)
Esto también se puede hacer
AddUser (userInfo)
¿Cuál de estos dos métodos es mejor? De un vistazo queda claro que el segundo método es definitivamente mucho mejor.
¿Cuándo usar tipos de variables comunes (int string)? guid double) para pasar parámetros entre capas? ¿Usar paso de modelo? Los siguientes métodos
SelectUser (int UserId)
SelectUserByName (cadena de nombre de usuario)
SelectUserByName (cadena de nombre de usuario cadena de contraseña)
SelectUserByEmail ( cadena de correo electrónico)
SelectUserByEmail (cadena de correo electrónico contraseña de cadena)
Se puede resumir como
SelectUser (userId)
SelectUser (usuario)
El usuario del objeto modelo se utiliza aquí para incluir cuatro modos de combinación de los tres parámetros: nombre de usuario, contraseña, correo electrónico. UserId en realidad se puede fusionar con usuario, pero otros BLL en el proyecto han implementado interfaces con parámetros de identificación, por lo que esto. El elemento también se conserva aquí
¿Cómo manejarlo después de que se pasa la información de usuario? Esto debe determinarse en orden y mediante un código específico
Aquí se procesa en este orden
p>
Primero verifique si hay nombre de usuario y contraseña, luego verifique si hay correo electrónico y contraseña, luego verifique si hay nombre de usuario, luego verifique si hay correo electrónico y procéselos en secuencia
De esta manera, si se agrega una nueva tarjeta de membresía de contenido (número) en el futuro, entonces no es necesario cambiar la interfaz, simplemente agregue soporte para el número en el código DAL y luego agregue el rendimiento y el procesamiento de la tarjeta de membresía. contenido en la interfaz
UserDAL cs
public IListlt; SelectUsers() Devuelve una lista de toda la información del usuario
public UserInfo SelectUser(int UserId) Devuelve la información de confianza del usuario especificado
public bool InsertUser(UserInfo U
ser) Agregar información de usuario
public bool UpdateUser (Usuario UserInfo) Actualizar información de usuario
public void DeleteUser (int UserId) Eliminar información de usuario
Muchas personas La mayoría Lo confuso es ¿qué parte de la capa de acceso a datos se considera la capa de acceso a datos? Algunas personas piensan que la base de datos es la capa de acceso a los datos, lo cual no es claro en cuanto a la definición. DAL es la capa de acceso a los datos en lugar de la capa de almacenamiento de datos, por lo que la base de datos no puede ser esta capa. Algunas personas también consideran SQLHelper (o sus componentes similares). ) como capa de acceso a datos. Es otra cosa prescindible. La función de SQLHelper es reducir la codificación repetitiva y mejorar la eficiencia de la codificación. Por lo tanto, si estoy acostumbrado a preocuparme por la eficiencia o usar una fuente de datos que no sea una base de datos, puedo descartar SQLHelper. ¿Cómo puede una parte que se puede descartar convertirse en una capa de tercer nivel en la arquitectura?
¿Se puede definir que el código relacionado con las operaciones de la fuente de datos debe colocarse en el acceso a los datos? capa y pertenece a la capa de acceso a datos
IUserDAL
La interfaz de la capa de acceso a datos es otra cosa prescindible porque ella y la fábrica de clases ClassFactory están incluidas en Petshop. Por lo tanto, algunos proyectos las incluyen. dos cosas independientemente de si necesitan admitir múltiples fuentes de datos o no. Algunos ni siquiera construyen un ClassFactory, pero solo se construye IDAL y luego IUserDAL iUserDal = new UserDAL(). completamente un anti-perro.
Mucha gente tiene un malentendido aquí, es decir, ¿piensan que existe tal relación BLL? àIDAL? àDAL Creo que IDAL actúa como un puente entre BLL y DAL llamados DAL. a través de IDAL, pero la realidad es que incluso si codifica IUserDAL de esta manera iUserDal = ClassFacotry CreateUserDAL(), UserDAL aún se ejecuta cuando se ejecuta la instancia de iUserDal SelectUsers() en lugar de una instancia de IUserDAL, por lo que la posición de IDAL en los tres. Las capas están al mismo nivel que DAL
A través de la introducción anterior, se explica básicamente la estructura jerárquica de la arquitectura de tres niveles. De hecho, tengo una opinión sobre la arquitectura de tres niveles. es reemplazar completamente cualquiera de las tres capas sin afectar las otras dos capas. Esta estructura básicamente cumple con el estándar de tres capas (aunque es más difícil de implementar ^_^, por ejemplo, si el proyecto se mueve de If). B/S se cambia a C/S (o viceversa), entonces no es necesario cambiar BLL y DAL excepto la interfaz de usuario. O si cambia SQLServer a Oracle, solo necesita reemplazar SQLServerDAL por OracleDAL. requerido, etc. Originalmente quería agregar algunos códigos específicos al artículo, pero no creo que sea necesario. Si crees que es necesario, agregaré más. lishixinzhi/Article/program/net/201311/11365. p>