Microsoft SQL Server Development: Banco de dados para desenvolvimento Multicamadas

Quando planejamos uma aplicaç�o devemos ter em mente que, independente do p�blico alvo inicial, uma aplicaç�o deve estar preparada para atender, mesmo que em um �nico segmento, clientes que podem ir desde um �nico terminal (com um �nico usu�rio) at� grupos empresariais (com dezenas ou centenas de filiais). Para atender este segundo cen�rio, as empresas geralmente, por possu�rem aplicaç�es constru�das em apenas duas camadas (Cliente/Servidor), utilizam a conex�o direta ao banco de dados atrav�s de redes de alta lat�ncia (Interna/Internet), ou a replicaç�o em lotes da informaç�o entre v�rios servidores de bancos de dados, os quais tamb�m utilizar�o redes de alta lat�ncia para isso. Al�m desse tipo de aplicaç�o, as empresas utilizam o serviço do Windows Terminal Server para integrar as unidades e possibilitar a centralizaç�o do processamento e armazenamento de dados.

As desvantagens em utilizar qualquer uma destas soluç�es s�o in�meras: alta lat�ncia e desempenho geral da aplicaç�o altamente prejudicado, possibilidade de inconsist�ncia de informaç�es, falhas de replicaç�o, elevados custos em infraestrutura para atender a virtualizaç�o de terminais, etc. Isso, sem citar a falta de segurança dos protocolos de bancos de dados que podem fazer com que dados cr�ticos trafeguem como texto plano pela rede.

Esta �ltima situaç�o pode ser contornada adicionando � comunicaç�o protocolos de criptografia e compress�o providos por outros componentes de software. Isso resolve o problema de segurança, mas traz mais um empecilho: este componente adicionado � comunicaç�o implica, obviamente, em uma carga extra de processamento em ambas as pontas da comunicaç�o. Alguns dir�o: "mas com os computadores atuais, esta carga adicional pode ser desprez�vel". Talvez, mas dependendo da lat�ncia da rede, mesmo comprimido e criptografado, ambas as pontas podem enfrentar problemas com o protocolo de comunicaç�o. Outra grande desvantagem do desenvolvimento Cliente/Servidor est� nos pr�prios desenvolvedores, pois muitos desenvolvedores utilizam o Delphi, C#, Java, por possu�rem IDEs RAD, est�o tremendamente acostumados a arrastar componentes, acessar seus eventos e escrever as regras de neg�cio dentro deles. Isso faz com que, ao inv�s de cumprir apenas o seu papel, que � receber e exibir dados, a interface com o usu�rio tamb�m controle as regras de neg�cio da aplicaç�o. Com isso, se dois ou mais formul�rios controlarem a mesma regra de neg�cio e esta estiver replicada em cada um deles, a manutenç�o em um �nico ponto n�o garante que esta manutenç�o seja replicada em cada um dos formul�rios, gerando diverg�ncias entre as regras.

E, por fim, aplicaç�es Cliente/Servidor possuem um baixo �ndice de integralidade, fazendo com que integraç�es com outras aplicaç�es sejam custosas e, na sua imensa maioria, constitu�das de uma s�rie de gambiarras artif�cios t�cnicos dispensados para soluç�o e/ou atendimento de necessidades levantadas segundo preceitos de engenharia de contorno. Isso faz com que a aplicaç�o integrada tenha uma regra espec�fica para processar as informaç�es que ser�o entregues � aplicaç�o integradora, o que pode, por falha no desenvolvimento da regra em uma das pontas, gerar diverg�ncias e erros na outra.

Visando resolver este problema, os cientistas dos laborat�rios da Xerox, durante o desenvolvimento do projeto Smalltalk, criaram um modelo de an�lise e desenvolvimento que, at� hoje, se mostra muito eficiente e que permite que v�rios componentes de software interajam entre si: a arquitetura multicamadas.

O que � Multicamadas

A arquitetura multicamadas estabelece que, para que um projeto seja eficiente e possua um baixo custo de manutenç�o e alta manutenibilidade, suas regras de neg�cio devem sempre ficar isoladas da interface com o usu�rio, de modo a n�o interferir em sua usabilidade e garantir a unificaç�o do processamento dos dados relativos � aplicaç�o. Estas regras deveriam estar igualmente isoladas dos dados a serem obtidos, manipulados ou persistidos, acoplando-se a eles o m�nimo poss�vel.

Alguns programadores acreditam que Multicamada � o MVC (Model View Controler) e isso n�o e verdade, tendo que MVC � um padr�o de projeto enquanto Multicamada � uma arquitetura, e ocorre pela a semelhança da estrutura. Planejar e construir um software sob a arquitetura MVC n�o implica em um desenvolvimento multicamadas (como pode ser visto no desenvolvimento web com PHP, Java, C#), assim como desenvolvimento multicamadas n�o est� limitado ao modelo imposto pela arquitetura MVC.

O planejamento e desenvolvimento de aplicaç�es multicamadas resolvem, por si s�, todos os problemas que o desenvolvimento Cliente/Servidor pode trazer: unifica as regras de neg�cio em apenas um ponto, estabelece um protocolo de comunicaç�o mais enxuto e leve (ideal para redes de alta lat�ncia), permite a utilizaç�o de interfaces com o usu�rio em m�ltiplas plataformas, reduz os custos de manutenç�o da aplicaç�o como um todo, aumenta sua manutenibilidade e, por consequ�ncia, seu ciclo de vida, etc. Ou seja, planejar e desenvolver aplicaç�es em m�ltiplas camadas agrega � pr�pria aplicaç�o uma gama infinita de possibilidades.

Quando necess�rio, aplicaç�es diversas podem integrar-se a aplicaç�es desenvolvidas sob esta arquitetura sem a necessidade da criaç�o de regras espec�ficas para a esta integraç�o. Aplicaç�es multicamadas geralmente t�m, para facilitar este processo, m�todos p�blicos que ser�o utilizados para estes fins, mantendo as regras de neg�cio apenas na aplicaç�o integradora, sem que a aplicaç�o integrada tenha que inteirar-se de suas particularidades em seu desenvolvimento.

Enfim, o modelo de desenvolvimento multicamadas se mostra infinitamente superior ao modelo Cliente/Servidor, pois possibilita, ao mesmo tempo, um ganho relativamente alto de performance em cen�rios cr�ticos como a possibilidade da expans�o dos horizontes da pr�pria aplicaç�o, que pode atender desde a menor das demandas at� aquelas em que o modelo de duas camadas � incapaz de atender.

Voc� vai encontrar em algumas literaturas diverg�ncia e vis�o de multicamadas entre os autores, tendo que a vis�o � ampla e alguns interpretam de jeitos diferentes mas com o mesmo resultado. Isso � errado? N�o, pois utilizam o conceito e aplicabilidade.

Algumas literaturas tratam o assunto multicamadas como sendo uma aplicaç�o em n camadas aquela desenvolvida de forma a ter v�rias camadas l�gicas e cada uma � auto-contida o suficiente, de forma que a aplicaç�o pode ser dividida em v�rios computadores em uma rede distribu�da.

A forma mais comum da arquitetura � a aplicaç�o em tr�s camadas(3-Tier), comumente usada em aplicaç�es web, na qual as camadas s�o:

Interface com o usu�rio (Camada de Apresentaç�o);
L�gica do neg�cio (Camada de Neg�cio) e
Banco de dados (Camada de Dados).

Cada camada desta arquitetura � normalmente mantida em um servidor espec�fico para tornar-se mais escalon�vel e independente das demais. Com o mesmo objetivo s�o utilizadas tecnologias de middleware como, por exemplo,CORBA,Web Services ou RMI.

Esta arquitetura tem como caracter�sticas:

Baixos custos de disponibilizaç�o;
Baixos custos na mudança da base de dados;
Baixos custos na mudança da l�gica de neg�cios;
Eficiente armazenamento e reutilizaç�o de recursos.

Muitos utilizam apenas tr�s camadas (DAL, BLL, UI) enquanto outros utilizam mais de tr�s camadas, no caso a MODEL que trata o modelo do banco de dados.

As Figuras 1 e 2 mostram como s�o divididas essas camadas de forma mais intuitiva.

Figura 1. Modelo Multicamadas mais interativo

Figura 2. Modelo mais simples de como � a comunicaç�o entre as camadas

Vamos entender um pouco de cada camada:

Camada Apresentaç�o (UI � User Interface Layer): A camada de apresentaç�o fica fisicamente localizada na estaç�o cliente e � respons�vel por fazer a interaç�o do usu�rio com o sistema. � uma camada bastante leve que basicamente executa os tratamentos de telas e campos e geralmente acessa somente a segunda camada, a qual faz as requisiç�es ao banco de dados e devolve o resultado. � tamb�m conhecida como cliente, regras de interface de usu�rio ou camada de interface.
Camada Regra de Neg�cio (BLL � Business Logic Layer): Em um sistema seguindo este modelo, a aplicaç�o cliente nunca acessa diretamente a �ltima camada que � a do banco de dados, pois quem tem essa funç�o � a camada de regras de neg�cios, na qual podem se conectar diversas aplicaç�es clientes.
Esta parte do sistema � respons�vel por fazer as requisiç�es ao banco de dados e todo o seu tratamento, ou seja, somente ela que tem acesso direto ao banco de dados. � tamb�m conhecida como l�gica de neg�cios, camada de acesso a dados, camada intermedi�ria ou servidor de aplicaç�o por geralmente se tratar de um outro computador destinado somente ao processamento das regras. O servidor de aplicaç�o � uma m�quina dedicada e com elevados recursos dehardware, uma vez que � nele que ficam armazenados os m�todos remotos (regras de neg�cios) e � realizado todo o seu tratamento e processamento.
Camada Banco de Dados (DAL � Data Access Layer): � a �ltima divis�o do modelo, na qual fica localizado o sistema gerenciador de banco de dados. � tamb�m conhecida como camada de dados.
Camada Modelo (Model): Essa camada tem a finalidade de ser o modelo do banco de dados, para melhor entendimento os campos do banco. Sempre que � efetuado uma requisiç�o de carregar informaç�es do banco ou at� mesmo pegar as informaç�es da tela precisa de uma classe que faça esse trabalho de transpor te de informaç�o e � essa classe que na qual eu utilizo.

Banco de Dados

Neste artigo o banco de dados a ser utilizado ser� o SQL SERVER 2012 que pode ser baixado no site da Microsoft.

Utilizaremos a linguagem de programaç�o de banco de dados T-SQL para a parte do CRUD, fazendo o uso de Stored Procedures e Views. Lembrando que cada banco de dados tem um conjunto espec�fico de comandos que definem a linguagem de programaç�o do banco de dados no caso do SQL Server � o Transaction SQL.

Antes de tudo vamos iniciar o Management Studio. Ap�s abrir o aplicativo, informe o Servidor, usu�rio e senha. Caso tenha colocado um usu�rio e senha, logar como autenticaç�o do SQL Server, caso contr�rio colocar Autenticaç�o do Windows, como ilustra a Figura 3.

Figura 3. Tela inicial do SQL Server Management Studio

Ap�s a autenticaç�o basta ir na opç�o NEW QUERY ou NOVA CONSULTA. Ap�s a abertura, cole o script abaixo para a criaç�o do banco de dados e observe o resultado na Figura 4:


CREATE DATABASE MULTICAMADAS 
GO

Figura 4. Script utilizado e o retorno do comando executado e o banco que foi criado

Ap�s criar a tabela, ser� necess�rio reiniciar ou atualizar o Management Studio. Antes de criar as tabelas primeiro � necess�rio criar uma nova query e informar qual � o banco de dados que ser� gerado as tabelas, como ilustra a Figura 5. Em seguida crie as tabelas com o script da Listagem 1.

Figura 5. Informaç�o do banco


/* 
* TABLE: TBL_ CLIENTE
Tabela de Cliente ir� armazenar o C�digo e Nome do Cliente.
*/

CREATE TABLE TBL_CLIENTE(
  ID_CLIENTE    int              IDENTITY(1,1),
  NM_CLIENTE    nvarchar(100)    NULL,
  CONSTRAINT PK5 PRIMARY KEY NONCLUSTERED (ID_CLIENTE)
)
go

/* 
* TABLE: TBL_ITENSPERFIL 
Tabela de Itens do Perfil armazena o c�digo, nome, descriç�o, 
permiss�o e c�digo do perfil dos itens do menu
*/

CREATE TABLE TBL_ITENSPERFIL(
  ID_ITENSPERFIL    int              IDENTITY(1,1),
  NM_MENU           nvarchar(100)    NOT NULL,
  DS_MENU           nvarchar(100)    NOT NULL,
  FG_PERMISSAO      nvarchar(1)      NULL,
  ID_PERFIL         int              NOT NULL,
  CONSTRAINT PK3 PRIMARY KEY NONCLUSTERED (ID_ITENSPERFIL)
)
go

/* 
* TABLE: TBL_PERFIL 
Tabela de Perfil armazena as informaç�es referente ao perfil de usu�rio
*/

CREATE TABLE TBL_PERFIL(
  ID_PERFIL    int              IDENTITY(1,1),
  DS_PERFIL    nvarchar(200)    NOT NULL,
  FG_ATIVO     nvarchar(1)      NULL,
  CONSTRAINT PK2 PRIMARY KEY NONCLUSTERED (ID_PERFIL)
)
go

/* 
* TABLE: TBL_PERMISSAOUSUARIO
Tabela Permiss�o de usu�rio armazena nome do formul�rio, 
descriç�o do formul�rio, opç�o de incluir, alterar, 
excluir e o c�digo do usu�rio
*/

CREATE TABLE TBL_PERMISSAOUSUARIO(
  ID_PERMISSAOUSUARIO    int             IDENTITY(1,1),
  DS_FORMULARIO          nvarchar(100)    NULL,
  NM_FORMULARIO          nvarchar(100)    NULL,
  FG_INCLUIR             nvarchar(1)     NULL,
  FG_ALTERAR             nvarchar(1)     NULL,
  FG_EXCLUIR             nvarchar(1)     NULL,
  ID_USUARIO             int             NOT NULL,
  CONSTRAINT PK4 PRIMARY KEY NONCLUSTERED (ID_PERMISSAOUSUARIO)
)
go


/* 
* TABLE: TBL_USUARIO 
Tabela de Usu�rio armazena o nome do usu�rio, login, senha, 
se est� ativo, se � supre usu�rio e o c�digo do perfil
*/

CREATE TABLE TBL_USUARIO(
  ID_USUARIO         int              IDENTITY(1,1),
  NM_USUARIO         nvarchar(100)    NOT NULL,
  DS_LOGIN           nvarchar(30)     NOT NULL,
  DS_SENHA           nvarchar(30)     NOT NULL,
  FG_ATIVO           nvarchar(1)      NULL,
  FG_SUPERUSUARIO    nvarchar(1)      NULL,
  ID_PERFIL          int              NOT NULL,
  CONSTRAINT PK1 PRIMARY KEY NONCLUSTERED (ID_USUARIO)
)
go


/* 
* TABLE: TBL_ITENSPERFIL
Cria o relacionamento entre a tabela de perfil e a de itens de perfil 
*/

ALTER TABLE TBL_ITENSPERFIL ADD CONSTRAINT RefTBL_PERFIL1 
  FOREIGN KEY (ID_PERFIL)
  REFERENCES TBL_PERFIL(ID_PERFIL)
go


/* 
* TABLE: TBL_PERMISSAOUSUARIO
Cria o relacionamento entre a tabela de usu�rio e permiss�o de usu�rio 
*/

ALTER TABLE TBL_PERMISSAOUSUARIO ADD CONSTRAINT RefTBL_USUARIO3 
  FOREIGN KEY (ID_USUARIO)
  REFERENCES TBL_USUARIO(ID_USUARIO)
go


/* 
* TABLE: TBL_USUARIO 
Cria o relacionamento entre a tabela de usu�rio e a tabela de perfil
*/

ALTER TABLE TBL_USUARIO ADD CONSTRAINT RefTBL_PERFIL2 
  FOREIGN KEY (ID_PERFIL)
  REFERENCES TBL_PERFIL(ID_PERFIL)
go

Listagem 1. Tabelas do banco de dados

Ap�s a criaç�o do banco de dados e suas tabelas vamos criar as Stored Procedures e Views. Para cada tabela ser�o criadas tr�s Stored Procedures sendo uma para cada aç�o, tais como o create, update e delete e uma Views.

Para criar Stored Procedures existe duas maneiras. Uma � ir no menu lateral Object Explorer/Pesquisador de Objeto e clicar em cima do banco criado MULTICAMADAS: aparecer� mais algumas opç�es, dentre as quais escolha a opç�o Armazenamento/Programmability e com o bot�o direito clique em cima de Procedimentos Armazenados/Stored Procedure e escolher a opç�o Novo Procedimento Armazenado/New Stored Procedure. A outra opç�o � abrir uma nova Query (Consulta) e digitar os comandos para a criaç�o.

As Listagens 2 a 4 mostram como criar as stored procedures da tabela Cliente para cada aç�o do CRUD.


CREATE PROCEDURE SP_TBL_CLIENTE_INSERT
    @NM_CLIENTE NVARCHAR(100)
AS
BEGIN
    INSERT INTO TBL_CLIENTE
    (
                NM_CLIENTE
    )
    VALUES
    (
                @NM_CLIENTE
    )
END

Listagem 2. Create(Insert) do Cliente


CREATE PROCEDURE SP_TBL_CLIENTE_UPDATE
    @ID_CLIENTE INT,
    @NM_CLIENTE NVARCHAR(100)
AS
BEGIN
    UPDATE TBL_CLIENTE
    SET
                NM_CLIENTE = @NM_CLIENTE
    WHERE ID_CLIENTE = @ID_CLIENTE
END

Listagem 3. Update Cliente


CREATE PROCEDURE SP_TBL_CLIENTE_DELETE
    @ID_CLIENTE INT
AS
BEGIN
    DELETE FROM TBL_CLIENTE
    WHERE ID_CLIENTE = @ID_CLIENTE
END

Listagem 4 � Delete Cliente

Ap�s a criaç�o da Stored Procedure iremos criar a View da tabela de cliente para recuperar os dados da tabela Cliente.

Para criar a View existem duas maneiras: uma � ir no menu lateral Object Explorer/Pesquisador de Objeto e clique em cima do banco criado MULTICAMADAS - clique com o bot�o direito em cima da opç�o Exibiç�es/Views e v� na opç�o Nova Exibiç�o/New View; ou abra uma nova Query(Consulta) e digite os comandos da Listagem 5 para a criaç�o.


CREATE VIEW VW_TBL_CLIENTE
AS
SELECT ID_CLIENTE
  ,NM_CLIENTE
FROM TBL_CLIENTE

Listagem 5. Read(Consulta) de Clientes

As Listagens 6 a 9 mostram a criaç�o das stored procedures e view da tabela de Usu�rios para cada aç�o do CRUD. As demais storeds procedures estar�o dispon�veis para download.


CREATE PROCEDURE SP_TBL_USUARIO_INSERT @NM_USUARIO NVARCHAR(100)
,@DS_LOGIN NVARCHAR(30)
,@DS_SENHA NVARCHAR(30)
,@FG_ATIVO NVARCHAR(1)
,@FG_SUPERUSUARIO NVARCHAR(1)
,@ID_PERFL INT
AS
BEGIN
INSERT INTO TBL_USUARIO (
  NM_USUARIO
  ,DS_LOGIN
  ,DS_SENHA
  ,FG_ATIVO
  ,FG_SUPERUSUARIO
  ,ID_PERFIL
  )
VALUES (
  @NM_USUARIO
  ,@DS_LOGIN
  ,@DS_SENHA
  ,@FG_ATIVO
  ,@FG_SUPERUSUARIO
  ,@ID_PERFL
  )
END

Listagem 6. Create(Insert) Usu�rio


CREATE PROCEDURE SP_TBL_USUARIO_UPDATE @ID_USUARIO INT
  ,@NM_USUARIO NVARCHAR(100)
  ,@DS_LOGIN NVARCHAR(30)
  ,@DS_SENHA NVARCHAR(30)
  ,@FG_ATIVO NVARCHAR(1)
  ,@FG_SUPERUSUARIO NVARCHAR(1)
  ,@ID_PERFIL INT
AS
BEGIN
  UPDATE TBL_USUARIO
  SET NM_USUARIO = @NM_USUARIO
    ,DS_LOGIN = DS_LOGIN
    ,DS_SENHA = DS_SENHA
    ,FG_ATIVO = FG_ATIVO
    ,FG_SUPERUSUARIO = @FG_SUPERUSUARIO
    ,ID_PERFIL = @ID_PERFIL
  WHERE ID_USUARIO = @ID_USUARIO
END

Listagem 7. Update Usu�rio


CREATE PROCEDURE SP_TBL_USUARIO_DELETE 
    @ID_USUARIO INT
AS
BEGIN
    DELETE FROM TBL_USUARIO
    WHERE ID_USUARIO = @ID_USUARIO
END

Listagem 8. Delete Usu�rio

A Listagem 9 mostra a criaç�o da view para a consulta de usu�rios.


CREATE VIEW VW_USUARIO
AS
SELECT T0.ID_USUARIO
  ,T0.NM_USUARIO
  ,T0.DS_LOGIN
  ,T0.FG_ATIVO
  ,T0.FG_SUPERUSUARIO
  ,T0.ID_PERFIL
  ,T1.DS_PERFIL
FROM TBL_USUARIO T0
INNER JOIN TBL_PERFIL AS T1 ON T1.ID_PERFIL 
= T0.ID_PERFIL

Listagem 9. Read(Consulta) de Usu�rio

Microsoft SQL Server Development: Banco de dados para desenvolvimento Multicamadas

Veja neste artigo como criar um banco de dados no SQL Server para atender o desenvolvimento em multicamadas de um aplicativo de controle de usuários com níveis de acesso tanto nos menus quanto nos formulários.

O que � Multicamadas

Banco de Dados

Artigos relacionados