BLL é a Camada de Lógica de Negócios
DAL é Camada de Acesso a Dados
Arquitetura de três níveis de ASP.NET (DAL, BLL, UI)
Os gráficos representam uma estrutura de três camadas. A web é a camada USL
Web –> Bll –> Dal
| | |
| V |
+–> modelo <—+
1. Arquitetura de três níveis
1. Camada de apresentação (USL): Ela representa principalmente o método WEB, mas também pode ser expressa como modo WINFORM. Se a camada lógica for bastante robusta e bem estabelecida, ela servirá perfeitamente independentemente de como a camada de desempenho seja definida e alterada.
2. Camada de lógica de negócios (BLL): principalmente para problemas específicos, também pode ser entendida como a operação da camada de dados e o processamento lógico do negócio de dados. Se a camada de dados é o bloco de construção, então a camada lógica é o bloco de construção.
3. Camada de acesso a dados (DAL): É principalmente a camada operacional dos dados originais (na forma de banco de dados, arquivo de texto ou outra forma de armazenamento), em vez dos dados originais, ou seja, a operação dos dados, não do banco de dados, especificamente da camada de lógica de negócios ou camada de apresentação
Fornecimento de serviços de dados.
2. Distinção específica
1. Camada de apresentação: aceita principalmente o pedido do usuário e retorna dados, fornecendo ao cliente acesso ao aplicativo.
2. Camada de lógica de negócios: principalmente responsável pela operação da camada de dados, ou seja, pela combinação de algumas operações da camada de dados.
3. Camada de acesso a dados: Depende principalmente se sua camada de dados contém processamento lógico; na verdade, suas funções completam principalmente várias operações no arquivo de dados, sem se preocupar com outras operações.
3. Resumo
A estrutura de três camadas é uma abordagem hierárquica estrita, ou seja, a camada de acesso a dados (DAL) só pode ser acessada pela camada de lógica de negócios (BLL), e a camada de lógica de negócios só pode ser acessada pela camada de apresentação (USL). Algumas estruturas de três camadas também adicionam outras camadas, como Fábrica e Modelo, que na verdade são uma extensão e aplicação com base nessas três camadas.
Um programa simples de três camadas geralmente inclui vários projetos do Modelo Web DAL BLL, e suas referências mútuas são as seguintes
1) WEB referências BLL, Model
2) BLL faz referência a DAL, modelo
3) Referências DAL Modelo
4) Modelo não possui citações
Quando se trata da arquitetura de três camadas, todos sabem que ela é a camada de desempenho (UI), a camada de lógica de negócios (BLL) e a camada de acesso a dados (DAL), e existem muitas formas de subdividir cada camada. Mas como escrever o código específico e em qual camada esses arquivos são contados é vago. A seguir está um exemplo simples para te levar a praticar um projeto de arquitetura de três camadas; este exemplo tem apenas uma função, que é: o gerenciamento simples dos usuários.
Primeiro, crie uma solução em branco e adicione os seguintes itens e arquivos
1. Adicionar um projeto de ASP.NET Aplicação Web, nomeá-lo UI e criar um novo arquivo de Formulário Web User.aspx (incluindo User.aspx.cs)
2. Adicionar um projeto ClassLibrary, nomeá-lo BLL e criar um novo arquivo Class UserBLL.cs
3. Adicionar um projeto ClassLibrary, nomeá-lo DAL e criar um novo arquivo Class UserDAL.cs. Adicione uma referência SQLHelper. (Esta é a classe de acesso a dados da Microsoft, ou você pode escrever todo o código de acesso aos dados diretamente.) Eu geralmente uso a classe DataAccessHelper que escrevo).
4. Adicionar um projeto ClassLibrary, nomeá-lo Modelo e criar um novo arquivo de tipo Class UserModel.cs
5. Adicionar um projeto ClassLibrary, nomeá-lo como IDAL e criar um novo arquivo de Interface IUserDAL.cs
6. Adicionar um projeto ClassLibrary e nomeá-lo ClassFactory
Acredito que você já viu que isso não é diferente do exemplo do Petshop, e é mais simples, porque também aprendo a arquitetura de três camadas pelo Petshop. No entanto, alguns amigos podem ser vagos sobre o nível desses projetos e a relação entre eles, aqui vai uma explicação sobre eles um a um:
1. User.aspx e User.aspx.cs
Ambos os documentos (e os itens aos quais o arquivo pertence, assim como os abaixo, não serão repetidos) fazem parte da camada de apresentação. User.aspx é mais fácil de entender porque é uma página de exibição. User.aspx.cs algumas pessoas acham que isso não deve ser contado, mas sim incluído na camada de lógica de negócios. Se você não faz camadas, não há problema em deixar User.aspx.cs lidar com a lógica de negócio e até mesmo operar o banco de dados, mas se você faz camadas, isso não deve ser feito. Em uma estrutura hierárquica, User.aspx.cs deve lidar apenas com conteúdo relacionado à exibição, e nada mais deve ser coberto.
Por exemplo, se implementarmos a função de exibir usuários na forma de uma lista, então o trabalho de extração das informações é feito pelo BLL, e após a interface (neste caso, é User.aspx.cs) chamar o BLL para obter UserInfo, ele fica vinculado ao controle de dados do User.aspx por meio do código para realizar a exibição da lista. Nesse processo, User.aspx.cs não desempenha um papel na interface, é usado apenas para passar dados, e como a maior parte da programação é implementada assim, algumas pessoas acham que User.aspx.cs não deve ser contado como UI, mas sim integrado ao BLL para processamento lógico. Olhando mais a fundo, foi proposto um novo requisito para adicionar um ícone na frente de cada usuário para representar vividamente o gênero do usuário, e para menores de 18 anos, ele era representado por um ícone de criança. A realização dessa exigência é a vez de User.aspx.cs, e neste caso User.aspx.cs ela tem um uso real.
2、NewBLL.cs
Adicione os seguintes métodos:
IList público GetUsers(): Retorna uma lista de todas as informações dos usuários
public UserInfo GetUser(int UserId): Retorna os dados do usuário especificado
public bool AddUser(UserInfoUser): Informações adicionadas do usuário
public bool ChangeUser(UserInfo User): Atualiza informações do usuário
public void RemoveUser(int UserId): Remove informações do usuário
Este arquivo pertence à camada de lógica de negócios e é dedicado a lidar com operações relacionadas à lógica de negócios. Muitas pessoas podem pensar que o único uso dessa camada é encaminhar os dados da camada de desempenho para a camada de dados. De fato, existem muitos desses casos, mas isso só pode significar que o projeto é relativamente simples, ou que a relação entre o próprio projeto e o negócio não está intimamente integrada (como o atual popular MIS), então a camada de negócio não tem nada a fazer e apenas desempenha um papel de encaminhamento. Mas isso não significa que a camada de negócio seja dispensável; à medida que o projeto cresce ou há mais relacionamentos comerciais, a camada de negócios refletirá seu papel.
O erro mais provável aqui é atribuir o código de operação de dados à camada de lógica de negócios e ao banco de dados como camada de acesso a dados.
Por exemplo, alguns amigos acham que a camada BLL não é significativa, mas eles apenas enviam os dados do DAL e encaminham para a interface sem nenhum processamento. Dê uma olhada neste exemplo
Camada BLL
SelectUser(UserInfo userInfo) obtém os dados do usuário com base no nome de usuário ou e-mail que chega.
IsExist(UserInfoUserInfo) determina se o nome de usuário ou e-mail especificado existe.
Então o DAL também fornece o método correspondente para a chamada BLL
SelectUser(UserInfoUserInfo)
IsExist(UserInfo userInfo)
Dessa forma, o BLL só tem um papel de transmissão.
Mas se você fizer:
BLL. IsExist(Userinfo userinfo)
{
Usuário UerInfo = DAL. SelectUser(User);
return (userInfo.Id != null);
}
Então o DAL não precisa implementar o método IsExist(), e há código lógico de processamento no BLL.
3、UserModel.cs
Entidade, essa coisa, você pode achar que não é fácil de estratificar. Incluindo eu, entendi assim: UI?àModel?àBLL?àModel?àDAL, então acredita-se que o Modelo atua como uma ponte para a transmissão de dados entre as camadas. Mas aqui, não pensamos em coisas simples, mas em complexidade.
O que é Modelo? Não é nada! É descartável em uma arquitetura de três níveis. Na verdade, é a coisa mais básica em programação orientada a objetos: classes. Uma tabela é uma classe, uma notícia também é uma classe, int, string, doublie, etc. também são classes, é apenas uma classe.
Dessa forma, a posição do modelo na arquitetura de três camadas é a mesma que o status de variáveis como int e string, e não tem outro propósito, sendo usado apenas para armazenamento de dados, mas armazena dados complexos. Portanto, se os objetos do seu projeto forem muito simples, você pode passar diretamente vários parâmetros sem um modelo para criar uma arquitetura de três camadas.
Então, por que você precisa de um modelo e quais são seus benefícios? O seguinte é o que vem à mente ao pensar sobre uma pergunta, inserido aqui:
O Modelo pode desempenhar um papel maior na passagem dos parâmetros em cada camada?
Ao passar parâmetros entre camadas, você pode fazer o seguinte:
AddUser(userId,userName,userPassword,...,)
Também pode ser assim:
AddUser(userInfo)
Qual desses dois métodos é melhor? À primeira vista, deve ser a segunda muito melhor.
Quando passar parâmetros entre camadas com tipos normais de variáveis (int, string, guid, double) e o que passar com o Model? Os seguintes métodos:
SelectUser(int UserId)
SelecionarNomeDeUsuário(nome de usuário com string)
SelecionarNomeDeUsuário(nome de usuário em string, senha em cadeia)
SelectUserByEmail(string email)
SelecioneUsuárioPorE-Mail (string de email, string password)
Pode ser resumido assim:
SelectUser(userId)
SelectUser(user)
Aqui usamos o objeto modelo de usuário para incluir quatro modos combinados: nome de usuário, senha e e-mail. O UserId também pode ser fundido com o user, mas outros BLL no projeto implementam interfaces com parâmetros de id, então esse item também é mantido.
userInfo é passado, então como lidar com isso, isso precisa ser na ordem de ordem, há um código específico para decidir.
Aqui é processado nesta ordem
Primeiro, veja se você tem nome de usuário e senha, depois veja se tem tanto e-mail quanto senha, depois veja se tem nome de usuário e então se tem e-mail. Processado sequencialmente.
Dessa forma, se um novo conteúdo for adicionado no futuro, o cartão de membro (número), não há necessidade de alterar a interface, basta adicionar suporte para número no código DAL e então adicionar o desempenho e processamento do conteúdo do cartão de membro em primeiro plano.
4、UserDAL.cs
public IList SelectUsers(): Retorna uma lista de todas as informações dos usuários
public UserInfo Select(int UserId): Retorna as informações confiáveis do usuário especificado
public bool InsertUser(UserInfoUser): Informação adicionada do usuário
public bool UpdateUser(UserInfo): Atualiza informações do usuário
public void DeleteUser(int UserId): Remove informações do usuário
O que muitas pessoas não conseguem entender mais é a camada de acesso a dados, qual parte é considerada camada de acesso a dados? Algumas pessoas acham que o banco de dados é a camada de acesso a dados, o que não está claro quanto à definição; DAL é a camada de acesso a dados e não a camada de armazenamento de dados, então o banco de dados não pode ser essa camada. O papel do SQLHelper é reduzir a codificação repetitiva e melhorar a eficiência da programação, então, se estou acostumado a me importar com eficiência ou a usar uma fonte de dados que não seja de banco de dados, posso descartar o SQLHelper, uma parte que pode ser descartada à vontade, como pode se tornar uma camada da arquitetura de três camadas.
Pode ser definido da seguinte forma: o código relacionado às operações da fonte de dados deve ser colocado na camada de acesso a dados, que pertence à camada de acesso a dados
5、IUserDAL
Interface da camada de acesso a dados, isso é outra coisa descartável, porque a Petshop traz junto com a ClassFactory Factory, então alguns projetos fazem essas duas coisas independentemente de precisarem suportar múltiplas fontes de dados ou não, e alguns até não compilam o ClassFactory, apenas o IDAL, e então "IUserDAL iUserDal = new UserDAL(); Não sei o que significa. Isso é completamente um tigre e não um anti-cachorro.
Muitas pessoas têm um equívoco aqui, ou seja, de que existe tal relação: BLL?àIDAL?àDAL, pensando que o IDAL atua como uma ponte entre BLL e DAL, e o BLL chama o DAL através do IDAL. Mas a realidade é que, mesmo que você codifique assim: "IUserDAL iUserDal = ClassFacotry.CreateUserDAL(); Ao executar "iUserDal.SelectUsers()", na verdade é a instância UserDAL que é executada, não a instância IUserDAL, então a posição do IDAL na terceira camada está relacionada ao nível DAL.
Por meio da introdução acima, a hierarquia da arquitetura de três níveis é basicamente explicada. Na verdade, tenho uma forma de julgar se a arquitetura de três camadas é padrão, ou seja, substituir completamente qualquer uma das três camadas não afetará as outras duas, e se essa estrutura basicamente atende ao padrão de três camadas (embora seja mais difícil ^_^ de implementar). Por exemplo, se você mudar o projeto de B/S para C/S (ou vice-versa), então BLL e DAL não precisam ser alterados, exceto pela interface; Ou mudar SQLServer para Oracle, apenas substituir SQLServerDAL por OracleDAL, nenhuma outra operação será necessária, etc. Originalmente, eu queria adicionar um código específico ao artigo, mas não acho necessário; se você achar necessário, eu adiciono.
Resumo: Não pense que uma camada é desnecessária só porque é inútil para você, ou porque é particularmente simples de implementar, ou abandona, ou usa para outros fins. Desde que as camadas sejam realizadas, não importa quantas camadas sejam, cada camada deve ter um propósito e uma função claros, e não deve ser influenciada pelo processo em si, resultando no mesmo tipo de arquivo localizado em camadas diferentes. Não deixe a mesma camada implementar funções diferentes. |
Publicado em 07/05/2015 10:53:35
|
|
|
