Então vamos ao que interessa. 1. Introdução

Transcrição

1 Tentarei ser o mais genérico possível. Nos exemplos irei utilizar ASP.Net 2.0 e acesso a dados através do ADO.NET, mas pode ter certeza que para outros casos a idéia não irá mudar muito, seja com LINQ, DAAB, NHIBERNATE, MVC ou qualquer outra tecnologia para acesso a dados. Então vamos ao que interessa. 1. Introdução Antes de começar, quero dizer que a arquitetura de um sistema vária de projeto para projeto, de necessidade para necessidade. Mas em sua maioria para projetos de médio e grande porte, utilizo as boas práticas de projetos de n-camadas (n-tier). Já para projetos pequenos, utilizo uma arquitetura minimizada (a qual não irei abordar aqui). É importante ter em mente que a organização demanda tempo. É bem mais rápido desenvolver um projeto de maneira desorganizada do que de maneira organizada. Mas as desvantagens de criar algo não pensado são inúmeras, como: dificuldade de manutenção, difícil refatoração, código não expressivo, entre outras. Então é bom pensar em tudo que for fazer, pensar em cada classe, método, propriedade, que for criar. Parece ser besteira, mas é sempre bom tomar cuidado com nomes e padrões que serão utilizados no projeto. Mas, sem maiores delongas: "Zelar pelo código que se faz". Em meus projetos costumo utilizar a seguinte arquitetura em camadas:

2 Parece ser bem simples não é? E é mesmo. Se tivermos cuidado na hora de arquitetar o sistema e se pensarmos em todos (maioria) dos detalhes do projeto como um todo, iremos ter um sistema fácil de dar manutenção, legível e modular. Alguns detalhes da arquitetura: - Devemos entender que as camadas de baixo referenciam as de cima. NUNCA devemos fazer o processo inverso. A única camada que não referência ninguém e todos conseguem enxerga-lá são as entidades. - Existem objetos próprios de cada camada, por exemplo, não iremos ter objeto da Namespace System.Data na camada da UI (Interface com o usuário). - Devemos lembrar que objetos que facilitam nossa vida como o SqlDataSource não estão de acordo com padrões de projetos de muitas empresas. Pelo simples fato que ao utilizá-lo estamos indo em contra mão ao ponto que diz (que uma camada se comunica, apenas, com a imediatamente acima). Ao adotarmos o SqlDataSource como controle para manipular dados em nossas aplicações, estamos fazendo com que a GUI acesse diretamente o banco de dados, e na prática apenas a DAL pode acessar nossos meios de persistência a dados. - As camadas podem estar distribuídas em máquinas/pastas diferentes, deste que cada camada seja uma DLL. Em outros casos as camadas podem estar dentro de nossas aplicações ASP.NET, sendo pastas na mesma.

3 - Os dados devem ser passados para as classes de cima sempre como entidade, ao invés de passar n parâmetros para as camadas de cima, criando assim uma dependência entre camadas. Caso eu adicione um atributo a mais em uma entidade, vou ter que adicionar um parâmetro a mais em meu método. Por exemplo: Não utilize esse tipo de método em seu código: public void InserirPessoaJuridica(string nome, string CPF, int idade); Bem mais simples passar apenas um objeto do que passar de parâmetros. public void InserirPessoaJuridica(PessoaJuridica pessoajuridica); OBS: O problema de se colocar todas as camadas em um único projeto é se um dia desejarmos criar aquela mesma aplicação para outro tipo de dispositivo. Por exemplo: Temos uma aplicação ASP.NET e desejamos agora criar uma opção para o usuário acessá-la via dispositivo móvel. Caso as camadas estejam em um único projeto, será bem trabalhoso de fazer isto. Já no caso de cada camada ser um projeto diferente, teremos apenas, que criar uma nova camada de UI e fazer com que esta referencie as outras camadas. Outros detalhes serão discutidos no decorrer deste artigo. Agora vamos falar sobre cada camada em particular. 1.1 GUI É a camada de interface com o usuário. No nosso caso é nossa aplicação ASP.NET. Poderia ser um projeto para dispositivo móvel, Windows Form, WPF, Silverlight. O ideal é que nessa camada encontremos apenas código que estejam diretamente relacionados com nossas páginas aspx. Já vi desenvolvedores de empresas grandes que faziam coisas esdrúxulas como acessar o bando direto da GUI. Além de deixar o código seboso, o trabalho de refazer o mesmo código inúmeras vezes será enorme. Então vamos seguir a regra, cada camada só enxerga a imediatamente acima. 1.2 Entidade

4 É a única camada que todos enxergam. Esta entidade contém nossas classes básicas (Ex: Pessoa, Médico, Casa, Cachorro, PessoaJuridica, PessoaFisica...). Classes que representam coisas do nosso mundo real. 1.3 Façade É um padrão faz com que tenhamos todas as funções do sistema em uma única classe. Uma possível implementação para este padrão é utilizar a palavra chave partial para ter vários arquivos físicos, mas que no final das contas será uma única classe. A finalidade disto é evitar ter um único arquivo enorme. OBS: Esta camada é optativa. Você pode acessar diretamente a camada de negócio. Costumo utilizar este padrão em casos onde preciso executar chamadas consecutivas ao banco em uma única operação. Por exemplo, no caso de uma transferência de conta bancária. Preciso retirar de uma pessoa e colocar na conta de outra. Então a façade serviria para fazer a chamada ao devidas funções. Teria o método Transferência na classe Façade, que este por sua vez iria ter o seguinte trecho de código: PessoaBus.Depositar(x); PessoaBus.Sacar(x); Ou seja utilizo essa classe apenas quando dou preferência a ter um local de fácil acesso que faça as operações na ordem de execução. 1.4 Business Tier Essa camada contém tudo que for lógica de negócio. Ela que irá fazer verificações e validações dos dados vindos e que ainda vão para o banco. É importante saber a diferencia entre regras de negócio e validações básicas. Pois existem validações que não precisam ser feitas necessariamente nesta classe. Como por exemplo, se o CPF é válido, pois essa é uma regra geral, e não de um específico sistema. A validação do CPF pode ser feita tanto do lado do cliente (javascript) como na camada de entidades. 1.5 DAL Única camada que acessa a dados. Esta camada é especifica para isso e nada mais. Então é uma boa prática evitar colocar validações nesta classe ou qualquer trecho de código que não esteja diretamente relacionado com acesso a dados.

5 Em muitos projetos tento criar camadas de acessos a dados genéricos. Mas isso não é obrigatório (dependendo do projeto, lógico). Se você sabe que aquele projeto sempre vai acessar apenas a um banco de dados (Sql Server, Oracle, Mysql, Postgres ou qualquer outro) e não tem a menor chance de mudar, então não existe a necessidade de criar uma camada genérica. OBS: Criar os repositórios para cada entidade e mapear cada tabela do banco em uma entidade dá muito trabalho. Então existem várias ferramentas que fazem esse trabalho para nós. São as ferramentas de mapeamento objeto relacionais. Temos em.net como exemplo: Nhibernate, SubSonic, LINQ. Temos um projeto da Microsoft que abstrai o acesso a banco de dados de nossa aplicação. É um projeto grande, que nos fornece muitas utilidades, que é a Microsoft Data Access Application Block. Caso você opte por utilizar alguma dessas ferramentas tudo bem. Mas muito cuidado ao escolher alguma delas. Pois alguns códigos gerados podem ir contra os padrões adotados em seu projeto, o que pode dar muita dor de cabeça ao tentar modificar o código gerado pela mesma. Quanto a conceitos de camadas, o que posso dizer é isso. Aconselho a estudar coisas relacionadas a design partner. Com bom conhecimento de padrões de projetos e bom conhecimento da regra de negócio da aplicação você será capaz de escrever aplicações bem arquitetadas e modeladas. 2. Codificando Como exemplo, vou mostrar um cadastro de pessoa bem simples. Apenas para dar idéia de como seria um sistema em camadas que costumo utilizar em alguns projetos pessoais. Porém, longe de ser o modelo ideal para suas aplicações. Para chegar a um modelo ideal para A aplicação procuro me sentar com toda a equipe de desenvolvimento (se não apenas os mais experientes) para discutirmos o modelo de nossa aplicação e de algumas classes. Para este exemplo, irei fazer uma aplicação ASP.NET e C# 2.0, acessando os dados com ADO.NET. Fazendo tudo isto na mão, sem o auxílio de ferramenta alguma. Bem, em meus projetos costumo começar de cima para baixo, ou seja, crio as camadas na seguinte sequência: Entidade -> DAL -> Business -> Façade -> GUI. Pois me faz pensar primeiramente no problema como um todo, e me faz refletir sobre as possíveis operações e necessidade do sistema. 2.1 Modelando o banco. O banco será bem simples, terá apenas a tabela pessoa.

6 O script para a tabela é: CREATE TABLE [dbo].[pessoa]( [id] [int] IDENTITY(1,1) NOT NULL, [nome] [nvarchar](100) NULL, [datanascimento] [smalldatetime] NULL, [sexo] [nchar](1) NULL, [ ] [nvarchar](50) NULL, [cpf] [nvarchar](15) NULL, CONSTRAINT [PK_Pessoa] PRIMARY KEY CLUSTERED ) 2.2. Entidade A camada de entidade é básica de se fazer, é basicamente um mapeamento das tabelas do banco. Para cada tabela do banco, teremos uma classe na camada de entidades. 1: public class Pessoa 2: { 3: #region Atributos 4: 5: private DateTime _datenascimento; 6: 7: #endregion 8: 9: #region Construtores 10: 11: public Pessoa() 12: { 13: 14: } 15: 16: public Pessoa(int id) 17: { 18: this.id = id; 19: }

7 20: 21: public Pessoa(string nome, DateTime datanascimento, char sexo, string , string cpf) 22: { 23: this.nome = nome; 24: this.datanascimento = datanascimento; 25: this.sexo = sexo; 26: this. = ; 27: this.cpf = cpf; 28: } 29: 30: public Pessoa(int id, string nome, DateTime datanascimento, char sexo, string , string cpf) 31: : this(nome, datanascimento, sexo, , cpf) 32: { 33: this.id = id; 34: } 35: 36: #endregion 37: 38: #region Propriedades 39: 40: public int ID { get; set; } 41: 42: public string Nome { get; set; } 43: 44: public DateTime DataNascimento 45: { 46: get 47: { 48: return this._datenascimento; 49: } 50: set 51: { 52: if (value > DateTime.Now) 53: { 54: throw new DataInvalidaException(); 55: } 56: else 57: { 58: this._datenascimento = value; 59: } 60: } 61: } 62: 63: public char Sexo { get; set; } 64: 65: public string { get; set; } 66: 67: public string Cpf { get; set; } 68: 69: #endregion 70: }

8 Dá para notar que na propriedade DataNascimento é feita uma validação. Essa validação pode ser feita nesta camada, pelo fato de ser uma validação básica, onde não muda de sistema para sistema. Ou seja, em todo local do mundo a data de nascimento de uma pessoa vai ser menos que a data atual Camada de acesso a dados Para criar as camadas de acesso a dados, costumo criar uma (ou mais) interfaces ou classes abstratas que servirão como base criar as classes de acesso a dados de cada entidade. Esta classe ou interface contém definições de métodos básicos, que sei que todas as classes vão conter, como por exemplo: Inserir, Atualizar, Recuperar por ID, Deletar. Para o exemplo, irei utilizar a seguinte interface: 1: /// <summary> 2: /// Interface com todos os métodos necessários para uma classe de DAO 3: /// </summary> 4: /// <typeparam name="t">tipo do objeto que será manipulador pela DAO</typeparam> 5: public interface IDataAccessObject<T> where T : new() 6: { 7: T Get<K>(K id); 8: 9: void Insert(T obj); 10: 11: void Update<K>(K id, T obj); 12: 13: void Delete<K>(K id); 14: } Esta é uma interface genérica que contém métodos básicos para outras classes. Alguns métodos são genéricos por recebem o tipo da chave primária da entidade (int, long, short). Outra classe da DAL que costumo utilizar é uma classe para auxiliar coisas como: criação de parâmetros, criação de comandos, entre outras operações. Como falei anteriormente, você pode utilizar a Microsoft Data Access Application Block para ajudar com esse tipo de coisas. Essa biblioteca contém inúmeros métodos. Para a aplicação de demonstração, irei utilizar uma classe bem simples que fiz apenas para esse exemplo. Detalhe que não estou abstraindo o banco da aplicação, mas aconselho você a criar uma classe que abstraia o banco que esta se utilizando. Outra observação é que está classe está incompleta,

9 fiz apenas para exemplo mesmo. Esta é uma classe que tem que ser bem pensada e bem trabalhada com a finalidade de obter melhor desempenho do banco de dados que está usando. Garanto que não será difícil modificar esta classe para ser genérica. Segue o código da mesma: 1: public class DatabaseHelper 2: { 3: #region Propriedades 4: 5: public SqlConnection MyBdConnection { get; set; } 6: public string NomeStringConexao { get; set; } 7: 8: #endregion 9: 10: #region Construtores 11: 12: public DatabaseHelper() 13: { 14: this.nomestringconexao = "DefaultStringConexao"; 15: this.mybdconnection = new SqlConnection(this.NomeStringConexao); 16: } 17: 18: public DatabaseHelper(string nomestringconexao) 19: { 20: 21: this.nomestringconexao = nomestringconexao; 22: this.mybdconnection = new SqlConnection(this.NomeStringConexao); 23: } 24: 25: #endregion 26: 27: #region Métodos Privados 28: 29: private string GetCorrectParameterName(string parametername) 30: { 31: if (parametername[0]!= '@') 32: { 33: parametername = "@" + parametername; 34: } 35: return parametername; 36: } 37: 38: #endregion 39: 40: #region Métodos Públicos 41: 42: public static DatabaseHelper Create() 43: { 44: return new DatabaseHelper(); 45: } 46: 47: public static DatabaseHelper Create(string nomestringconexao) 48: { 49: return new DatabaseHelper(nomeStringConexao);

10 50: } 51: 52: public void OpenConnection() 53: { 54: if (this.mybdconnection.state == System.Data.ConnectionState.Closed) 55: { 56: this.mybdconnection.open(); 57: } 58: } 59: 60: public void CloseConection() 61: { 62: this.mybdconnection.close(); 63: } 64: 65: public SqlParameter BuildParameter(string nome, object valor, DbType tipo, int size) 66: { 67: SqlParameter parametro = new SqlParameter(this.GetCorrectParameterName(nome), valor); 68: parametro.dbtype = tipo; 69: parametro.size = size; 70: return parametro; 71: } 72: 73: public void BuildParameter(string nome, object valor, DbType tipo, int size, List<SqlParameter> listparametros) 74: { 75: SqlParameter parametro = this.buildparameter(nome, valor, tipo, size); 76: listparametros.add(parametro); 77: } 78: 79: public SqlParameter BuildOutPutParameter(string nome, DbType tipo, int size) 80: { 81: SqlParameter parametro = new SqlParameter(); 82: parametro.parametername = this.getcorrectparametername(nome); 83: parametro.dbtype = tipo; 84: parametro.size = size; 85: parametro.direction = ParameterDirection.Output; 86: return parametro; 87: } 88: 89: public void BuildOutPutParameter(string nome, DbType tipo, int size, List<SqlParameter> listparametros) 90: { 91: SqlParameter parametro = this.buildoutputparameter(nome, tipo, size); 92: listparametros.add(parametro); 93: } 94: 95: public void ExecuteNonQuery(SqlCommand command) 96: { 97: command.executenonquery(); 98: } 99: 100: public void ExecuteNonQuery(SqlCommand command, bool openconnection) 101: {

11 102: if (openconnection) 103: { 104: this.openconnection(); 105: } 106: this.executenonquery(command); 107: if (openconnection) 108: { 109: this.closeconection(); 110: } 111: } 112: 113: public void ExecuteNonQuery(string query, params SqlParameter[] parameters) 114: { 115: Exception erro = null; 116: try 117: { 118: this.openconnection(); 119: SqlCommand command = this.mybdconnection.createcommand(); 120: command.commandtext = query; 121: command.parameters.addrange(parameters); 122: this.executenonquery(command); 123: this.closeconection(); 124: } 125: catch (Exception ex) 126: { 127: erro = ex; 128: } 129: finally 130: { 131: this.closeconection(); 132: } 133: 134: if (erro!= null) 135: { 136: throw erro; 137: } 138: } 139: 140: public void ExecuteCommands(params SqlCommand[] commands) 141: { 142: Exception erro = null; 143: SqlTransaction trans = null; 144: try 145: { 146: this.mybdconnection.open(); 147: trans = this.mybdconnection.begintransaction(); 148: for (int i = 0; i < commands.length; i++) 149: { 150: commands[i].transaction = trans; 151: this.executenonquery(commands[i]); 152: } 153: trans.commit(); 154: this.mybdconnection.close(); 155: }

12 156: catch(exception ex) 157: { 158: trans.rollback(); 159: erro = ex; 160: } 161: finally 162: { 163: this.mybdconnection.close(); 164: } 165: 166: if (erro!= null) 167: { 168: throw erro; 169: } 170: } 171: 172: #endregion 173: } Para criar essa classe auxiliar deve se considerar muitas coisas: - Abrangência; -Desempenho; - Utilização de cachê ou não; - Objetos que serão utilizados para manipular os dados (DataDet, DataTable, SqlDataReader); - Se será utilizado apenas stored procedure ou se todas as querys vão estar na aplicação. -...; Já temos uma interface para nossa camada de acesso a dados e uma classe que irá nos auxiliar com a mesma. Agora nos resta criar as classe de acesso para cada entidade presente em nosso projeto. O código da nossa classe Pessoa será o seguinte: 1: public class PessoaDAO : IDataAccessObject<Pessoa> 2: { 3: #region Atributos 4: 5: private DatabaseHelper databasehelper; 6: 7: #endregion 8: 9: #region Construtores 10: 11: public PessoaDAO() 12: {

13 13: databasehelper = DatabaseHelper.Create(); 14: } 15: 16: #endregion 17: 18: #region IDataAccessObject<Pessoa> Members 19: 20: public Pessoa Get<K>(K id) 21: { 22: Pessoa pessoa = new Pessoa(); 23: SqlDataReader reader = null; 24: try 25: { 26: string query = "SELECT * FROM Pessoa WHERE id 27: databasehelper.openconnection(); 28: reader = databasehelper.executedatareader(query, 29: new SqlParameter("id", id)); 30: while (reader.read()) 31: { 32: pessoa.nome = reader["nome"].tostring(); 33: pessoa.cpf = reader["cpf"].tostring(); 34: pessoa.datanascimento = Convert.ToDateTime(reader["dataNascimento"]); 35: pessoa. = reader[" "].tostring(); 36: pessoa.id = Convert.ToInt32(reader["nome"]); 37: } 38: reader.close(); 39: this.databasehelper.closeconection(); 40: } 41: finally 42: { 43: if (reader!= null) 44: { 45: reader.close(); 46: } 47: this.databasehelper.closeconection(); 48: } 49: return pessoa; 50: } 51: 52: public void Insert(Pessoa obj) 53: { 54: string query = "INSERT INTO PESSOA (nome, datanacimento, cpf, , sexo) 55: this.databasehelper.executenonquery(query, 56: new SqlParameter("nome", obj.nome), 57: new SqlParameter("dataNascimento", obj.datanascimento), 58: new SqlParameter("cpf", obj.cpf), 59: new SqlParameter(" ", obj. ), 60: new SqlParameter("sexo", obj.sexo)); 61: } 62: 63: public void Update<K>(K id, Pessoa obj) 64: { 65: throw new NotImplementedException();

14 66: } 67: 68: public void Delete<K>(K id) 69: { 70: throw new NotImplementedException(); 71: } 72: 73: #endregion 74: } Simples não é?! A implementação dos métodos de delete e update, eu deixo como exercício para você. :D 2.3. Camada de Negócio A idéia da camada de negócio é bastante simples. Como falei anteriormente, ela tem o papel de acessar a camada de dados e é quem fará validações em cima da mesma. Geralmente, assim como a camada de DAL, costumo criar uma interface nessa camada com os métodos mais utilizados. Mas para exemplo irei mostrar apenas o método insert da classe de negócio de pessoa. 1: public class PessoaBus 2: { 3: private PessoaDAO pessoadao; 4: 5: public PessoaBus() 6: { 7: this.pessoadao = new PessoaDAO(); 8: } 9: 10: public void Inserir(Pessoa pessoa) 11: { 12: //caso haja validação, ela pode ser feita neste método mesmo. 13: this.pessoadao.insert(pessoa); 14: } 15: } Um padrão que costumo utilizar nessa camada são as factories. Que tem o papel de criar instâncias das classes. Ou seja, com esse padrão eu consigo ter acesso a qualquer objeto acessando apenas uma classe. Exemplo de Factory: 1: public static class FactoryDAO 2: { 3: public static ContatoDAO CreateContatoDAO() 4: { 5: return new ContatoDAO();

15 6: } 7: 8: public static ContatoDAO CreatePessoaDAO() 9: { 10: return new PessoaDAO(); 11: } 12: } 2.4. Façade Tier Façade é simples o bastante que dispensa palavras. Então vamos ao exemplo: Arquivo 1: Facade.cs 1: public partial class Facade 2: { 3: private PessoaDAO _pessoadao; 4: private ContatoDAO _contatodao; 5: 6: public Facade() 7: { 8: _contatodao = FactoryDAO.CreateContatoDAO(); 9: _pessoadao = FactoryDAO.CreatePessoaDAO(); 10: } 11: } Arquivo 2: PessoaFacade.cs 1: public partial class Facade 2: { 3: public void InserirPessoa(Pessoa pessoa) 4: { 5: this._pessoadao.insert(pessoa); 6: } 7: 8: public void UpdatePessoa(int id, Pessoa pessoa) 9: { 10: this._pessoadao.update<int>(id, pessoa); 11: } 12: 13: public Pessoa GetPessoa(int id) 14: { 15: return this._pessoadao.get<int>(id); 16: } 17: 18: public void DeletePessoa(int id) 19: {

16 20: 21: } 22: } this._pessoadao.delete<int>(id); OBS: Notar o uso da palavra chave partial UI Tier Não irei mostrar exemplo de código desta camada. Pois este é o nosso projeto ASP.NET que já sabemos. A única coisa que devemos fazer nessa camada é encapsular os dados no objeto Pessoa, por exemplo e em seguida passar o mesmo para algum método da Façade. Bem, espero ter ajudado. O básico de uma boa arquitetura de sistema é isto. Pode ter certeza que lendo esse material, depois de ter entendido o mesmo por completo e depois ler profundamente sobre padrões de projetos você estará totalmente apto para criar uma aplicação bem modelada e arquitetada. Em outra oportunidade escreverei um pouco mais sobre arquitetura em camadas e trarei exemplos de sistemas bem arquitetados. Abraços.