Arquitectura de 3 Camadas
A arquitectura de 3 camadas ou 3-Tier Architecture é uma arquitectura de desenvolvimento baseada em separar uma aplicação em 3 camadas: User Interface, Business Layer e DataAcess Layer.
Implementar a lógica da aplicação na camada Business Layer pode aumentar bastante a reusibilidade de uma aplicação. Como?
Imaginem o seguinte cenário:
um cliente pede para que seja desenvolvida uma aplicação Web para gerir o armazém dele. Desenvolvemos um website, é validada a informação antes de ser enviada para a base de dados, e tudo está a funcionar muito bem. 3 meses depois o cliente pede que seja desenvolvida outra aplicação mas para dispositivos mobile só para a consulta dos pedidos em transporte. O que vai acontecer se estamos a fazer as validações, chamadas à base e dados e outros processos todos no code behind das páginas (webforms) ou mesmo que esteja tudo numa classe, mas hà parâmetros dos métodos que precisamos de alterar, desta vez precisamos de utilizar webservices (e por aí adiante).
Como fazer este novo projecto? "Copiar -> Colar" grande parte dos métodos?
Se a aplicação tivesse separada em camadas, uma solução seria criar apenas webservices que acedessem à camada de negócio, retornassem os dados e apenas a apresentação (User Interface) seria diferente, adaptada a dispositivos móveis)
- User Interface - Camada apresentada ao utilizador.
Podem ser páginas aspx, um aplicativo silverligth, etc. É importante relembrar que tudo que for incluído aqui vai ser exposto ao utilizador, o que é uma grande preocupação a nível de vulnerabilidades da aplicação. Por exemplo, construir queries em javascript (nem sei como é possível ter lido um artigo a retratar isso) é uma vulnerabilidade a injecção SQL, enviar dados como a sessão do utilizador e outros dados que podem ser mantidos no lado do servidor deve ser evitado
- Business Layer - Camada do negócio da aplicação.
Nesta camada eu são recebidos os dados do utilizador, feitas as validações necessárias, tratamento de erros, etc.
- Data Acess Layer - Camada que vai aceder à nossa fonte de dados. Se a aplicação usar um ORM (ie: nHibernate, EF) é nestas camadas que são construídas as instruções SQL, instruções LINQ, chamadas a stored procedures, abrir e fechar as ligações à base de dados, etc.
Analisando esta arquitectura num exemplo muito básico.
UI
<label for='loginUtilizador'>Utilizador:</label> <input type='text' id='loginUtilizador' /> </br>
<label for='loginPassword'>Utilizador:</label> <input type='text' id='loginPassword' />
<input type='button' value='Autenticar' onclick='Login();' />
<script type="text/javascript">
function Login() {
$.ajax({
type: "POST",
url: "Webservices/Utilizador.asmx/Autenticacao",
data: "{ 'utilizador' : '" + utilizador + "', 'password' : '" + password + "'}",
success: function(msg){
alert(msg.d);
}
});
}
</srcript>
Business
internal class UserService {
private UserData _userData = new UserData();
public string Autenticar(string utilizador, string password) {
// aqui pdemos encriptar a password caso ela esteja assim guardada na base de dados
// validamos a variável utilizador e password
bool resultado = _userData.Autenticar(utilizador, password);
if(resultado) {
// criamos uma sessão de autenticação por exemplo
}
return (resultado) ? "Autenticação realizada com sucesso" : "Login ou Password incorrectos";
}
}
Data
internal class UserData {
public bool Autenticar(string utilizador, string password) {
// ligação à base de dados, enviar os dados para a autenticação e retornar uma mensagem
return true;
}
}
WebService
[WebService(Namespace = "http://tempuri.org/")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
[System.ComponentModel.ToolboxItem(false)]
[System.Web.Script.Services.ScriptService]
public class Utilizador : System.Web.Services.WebService
{
private UserService _userService = new UserService();
[WebMethod]
public string Autenticar (string utilizador, string password)
{
return _userService.Autenticar(utilizador, password);
}
}
Eu tenho por hábito usar sufixos para as Entidades de cada camada. AlunosService, AlunosData, ProfessoresService, ProfessoresData, etc.
Torna a leitura do código um pouco mais fácil para programadores que não tenham trabalho no projecto.
|
Microsoft .NET: Architecting Applications for the Enterprise (PRO-Developer)
Pela recomendação do João Manso deixo aqui o link a este livro.
- Build testability, maintainability, and security into your system early in the design
- Expose business logic through a service-oriented interface
- Choose the best pattern for organizing business logic and behavior
- Review and apply the patterns for separating the UI and presentation logic
- Delve deep into the patterns and practices for the data access layer
- Tackle the impedance mismatch between objects and data
- Minimize development effort and avoid over-engineering—and deliver more robust results
Amazon: http://www.amazon.co.uk/Microsoft-NET-Architecting-Applications-PRO-Developer/dp/073562609X
|