Mapeamento Objeto-Relacional Usando o TMS Aurelius

Transcrição

1 Mapeamento Objeto-Relacional Usando o TMS Aurelius Desenvolver sistemas com banco de dados é um dos usos mais comuns do Delphi. Porém lidar com comandos SQL pode ser uma tarefa enfadonha. Em geral, ao construirmos um sistema de banco de dados, o processo é geralmente o mesmo: 1. Configurar uma conexão 2. Criar um TSQLQuery ou outro descendente de TDataset que execute comandos SQL 3. Montar o comando SQL e executá-lo via TSQLQuery 4. Abrir o TDataset e rer os registros lendo os valores usando objetos TField Tem sido mais ou menos assim desde o início do Delphi e obviamente é um método consagrado - mas tem suas desvantagens. Temos que montar o SQL manualmente e lembrar os nomes dos campos e tabelas no banco, tanto na hora de montar a SQL quanto na hora de ler os valores. Se fizermos um refactor do banco, temos que rever todos os nossos comandos SQL. Como alternativa, podemos usar uma framework de mapeamento objeto-relacional. Com ela, o processo é diferente: nós fazemos um mapeamento inicial, para informar como cada classe será salva no banco de dados e, a partir daí, não trabalhamos mais com SQL ou TDataset: manipulamos apenas os objetos. O objetivo deste artigo é mostrar como usar uma framework de mapeamento objeto-relacional pra construir aplicações de bancos de dados. A framework utilizada será o TMS Aurelius ( Criando uma conexão A primeira coisa a se fazer é configurar uma conexão ao banco de dados. O TMS Aurelius não exige que você aprenda quase nada de novo aqui, porque na verdade ele não tem componentes de conexão ao banco de dados ele simplesmente utiliza os que você tem na sua aplicação. São disponibilizados adapters onde você apenas passa o componente de conexão que você utiliza. A listagem 1 mostra como obter uma conexão do Aurelius a partir de uma conexão dbexpress. Listagem 1 Criando uma conexão uses Aurelius.Drivers.Interfaces, Aurelius.Drivers.dbExpress; Conexao: IDBConnection; Conexao := TDbExpressConnectionAdapter.Create(SQLConnection1, False); O componente SQLConnection1 é um componente dbexpress do tipo TSQLConnection que já existe na sua aplicação, ou que você tenha criado só pro Aurelius. É lá que você irá configurar sua conexão e, para usá-la no Aurelius, apenas use o adapter pra obter uma interface IDBConnection. Essa iável Conexao que criamos na Listagem 1 será usada em todos os exemplos daqui pra frente.

2 Existem adapters para vários tipos de componentes. Se você não usa o dbexpress e portanto não tem um componente TSQLConnection, você pode usar o SQL-Direct (TSDDatabase), AnyDac (TADConnection), IBX (TIBDatabase), ADO (TADOConnection) e vários outros. O Aurelius também irá criar os comandos SQL de acordo com os banco de dados ao qual a aplicação está se conectando. No caso do dbexpress ele detectou automaticamente o tipo de banco com base na propriedade DriverName do TSQLConnection, mas você pode especificar explicitamente qual banco você está utilizando. As opções são muitas: Oracle, SQL Server, Interbase, Firebird, MySQL, Nexus, DB2, SQLite, PostgreSQL, entre outros. Mapeando a classe Você pode utilizar uma classe já existente ou criar uma classe nova. O Aurelius possui o recurso de automapeamento, o que facilita bastante. Veja o exemplo da listagem 2. Listagem 2 Mapeamento automático de classe [Automapping] TPessoa = class private FId: integer; FNome: string; FCidade: string; FTelefone: string; property Id: integer read FId; property Nome: string read FNome write FNome; property Cidade: string read FCidade write FCidade; property Telefone: string read FTelefone write FTelefone; Na listagem 2, estamos dizendo: essa classepode ser salva no banco (Entity) e deve ser feito um mapeamento automático dos campos (Automapping). O Aurelius irá sal essa classe na tabela Pessoa, que terá quatro campos: Id, Nome, Cidade e Telefone, o primeiro do tipo integer e os demais do tipo char. Você pode definir tudo isso manualmente, usando atributos. Isso pode ser útil se você já tiver uma aplicação existente, com tabelas já definidas, e quer apenas começar um novo módulo na aplicação usando o Aurelius. Nesse caso você cria sua classe do jeito que você quer e faz um mapeamento manual à tabela e campos existentes, como no exemplo da listagem 3. Listagem 3 Mapeamento manual de classe [Automapping] [Table( TBL_PESSOAS )] [Sequence( SEQ_PESSOAS )]

3 [Id('FId', TIdGenerator.IdentityOrSequence)] TPessoa = class Private [Column('PS_ID', [TColumnProp.Unique, TColumnProp.Required, TColumnProp.NoUpdate])] FId: integer; [Column('PS_NOMEPESSOA_A', [TColumnProp.Required], 100)] FNome: string; [Column('PS_CIDADE_A', [TColumnProp.Required], 50)] FCidade: string; [Column('PS_FONE_A', [TColumnProp.Required], 15)] FTelefone: string; property Id: integer read FId; property Nome: string read FNome write FNome; property Cidade: string read FCidade write FCidade; property Telefone: string read FTelefone write FTelefone; Criando o banco de dados Opcional Você pode criar as tabelas e campos automaticamente, baseado nas classes que você definiu e mapeou. Claro que se você já tem um banco existente, não precisa realizar essa etapa. A listagem 4 mostra como criar a estrutura do banco: Listagem 4 Criando o banco de dados DatabaseManager: TDatabaseManager; DatabaseManager := TDatabaseManager.Create(Conexao); DatabaseManager.BuildDatabase; DatabaseManager.Free; Gerando classes a partir do banco de dados Como mencionamos, se o banco já existe você pode apenas criar a classe e mapeá-la para a tabela e campos existentes. Pra facilitar esse trabalho, o Aurelius trabalha integrado com a ferramenta Data Modeler. Essa ferramenta permite que você importe toda a estrutura do banco de dados para modelagem e, além dos recursos de comparação de bancos, geração de scripts SQL de criação e atualização do banco, também possui uma opção para gerar automaticamente um código-fonte com todas as classes já mapeadas, a partir das tabelas existentes. Figura 1 Opção para criação de classes a partir da estrutura do banco

4 A geração de classes é bem flexível você pode gerar automaticamente a partir das configurações padrão, ou pode utilizar a janela de configuração pra definir o mapeamento específico qual classe será criada, qual propriedade, etc.. A figura 2 mostra uma parte de um banco de dados importado pelo Data Modeler, e a listagem 5 é um exemplo de uma classe gerada automaticamente, pra tabela Orders. Figura 2 Tabelas existentes no banco Listagem 5 Classe mapeada gerada automaticamente pelo Data Modeler [Table('Orders')] [Id('FOrderID', TIdGenerator.IdentityOrSequence)] TOrder = class private [Column('OrderID', [TColumnProp.Required, TColumnProp.NoInsert, TColumnProp.NoUpdate])] FOrderID: integer; [Column('OrderDate', [])]

5 FOrderDate: Nullable<TDateTime>; [Column('ShippedDate', [])] FShippedDate: Nullable<TDateTime>; [Association] [JoinColumn('CustomerID', [], 'CustomerID')] FCustomer: Proxy<TCustomer>; [Association] [JoinColumn('EmployeeID', [], 'EmployeeID')] FEmployee: Proxy<TEmployee>; [ManyValuedAssociation([], [TCascadeType.SaveUpdate, TCascadeType.Merge], 'FOrderID')] FOrderDetailsList: Proxy<TList<TOrderDetails>>; function GetCustomer: TCustomer; procedure SetCustomerID(const Value: TCustomers); function GetEmployee: TEmployee; procedure SetEmployee(const Value: TEmployee); function GetOrderDetailsList: TList<TOrderDetails>; constructor Create; destructor Destroy; override; property OrderID: integer read FOrderID; property OrderDate: Nullable<TDateTime> read FOrderDate write FOrderDate; property ShippedDate: Nullable<TDateTime> read FShippedDate write FShippedDate; property Customer: TCustomer read GetCustomer write SetCustomer; property Employee: TEmployee read GetEmployee write SetEmployee; property OrderDetailsList: TList<TOrderDetails> read GetOrderDetailsList; Salvando objetos no banco Uma vez definida a conexão, o mapeamento e, com as tabelas prontas no banco de dados, é hora de começar efetivamente a construir a aplicação. Como mencionado, a partir de agora toda a aplicação fica baseada em objetos. A listagem 6 mostra como criar uma nova pessoa no banco de dados: Listagem 6 Salvando um objeto Pessoa: TPessoa; Manager: TObjectManager; Pessoa := TPessoa.Create; Pessoa.Nome := 'Oswaldo'; Pessoa.Cidade := 'Sao Paulo'; Pessoa.Telefone := '(11) '; Manager := TObjectManager.Create(Conexao); Manager.Save(Pessoa); Manager.Flush; IdPessoa := Pessoa.Id;

6 Manager.Free; Até a criação do TObjectManager, o código é Delphi puro e simples apenas manipulação de objetos. Então criamos um gerenciador (de objetos), o TObjectManager, pra sal esse objeto no banco. Note que passamos para o gerenciador a interface Conexao que criamos anteriormente. O método Save informa que estamos salvando um objeto novo, e o método Flush diz ao gerenciador para efetuar no banco todas as alterações que fizemos (no caso, solicitamos um salvamento). O Aurelius então irá montar a SQL, setar os parâmetros de acordo com as propriedades do objeto, e efeutar o INSERT na tabela. Se você está usando um Id do tipo identity ou sequence, você pode obter o valor gerado através da propriedade Id, conforme o exemplo. Outra observação importante: note que não destruímos o objeto Pessoa. Isso não é um memory leak uma vez que o objeto passa a ser gerenciado pelo TObjectManager (nesse caso quando chamamos o Save), ele será destruído automaticamente quando não for mais necessário. Assim podemos usar os objetos tranquilamente, inclusive as associações, sem nos preocuparmos em destruí-los. Atualizando objetos Para atualizar objetos já existentes, basta buscá-los, alterá-los e chamar o Flush novamente. A listagem 7 mostra como alterar o telefone da pessoa que acabamos de criar. Listagem 7 Atualizando objetos Manager: TObjectManager; Pessoa: TPessoa; Manager := TObjectManager.Create(Connection); Pessoa := Manager.Find<TPerson>(IdPessoa); Pessoa.Telefone := (11) ; Manager.Flush; Manager.Free; É interessante notar que o Aurelius detecta apenas as propriedades alteradas (no caso Telefone) e executa o Update atualizando apenas esse campo. Isso ajuda o desempenho em aplicações multiusuário e evita que um usuário sobrescreva o que o outro alterou. O SQL executado seria o seguinte (considerando o mapeamento manual da listagem 2): UPDATE TBL_PESSOAS SET PS_FONE_A=:p0 WHERE PS_ID=:p1;

7 Herança Um recurso interessante do Aurelius é o suporte a herança. Como estamos trabalhando com classes e objetos, é útil e sensato que herança, um recurso básico de orientação a objetos, possa ser utilizada. Por exemplo, podemos criar as seguintes novas classes (Listagem 8): Listagem 8 Classes herdadas [Automapping] [Inheritance(TinheritanceStrategy.JoinedTables)] [Table( TBL_PESSOAFISICA )] TPessoaFisica = class(tpessoa) private FCPF: string; property CPF: string read FCPF write FCPF; [Automapping] [Inheritance(TinheritanceStrategy.JoinedTables)] [Table( TBL_PESSOAJURIDICA )] TPessoaJuridica = class(tpessoa) private FCNPJ: string; property CNPJ: string read FCNPJ write FCNPJ; Nesse caso, o Aurelius irá criar duas novas tabelas, TBL_PESSOAFISICA e TBL_PESSOAJURIDICA, ambas relacionadas à tabela TBL_PESSOA através de uma chave estrangeira. A tabela da pessoa física terá um campo CPF e a da jurídica um campo CNPJ. É possível também configurar o Aurelius pra sal todas as classes em uma mesma tabela. A listagem 9 mostra como sal uma classe TPessoaJuridica. Listagem 9 salvando uma classe herdada Pessoa: TPessoaJuridica; Manager: TObjectManager; Pessoa := TPessoa.Create; Pessoa.Nome := 'Embarcadero'; Pessoa.Cidade := 'Sao Paulo'; Pessoa.Telefone := '(11) '; Pessoa.CNPJ := / ; Manager := TObjectManager.Create(Conexao); Manager.Save(Pessoa);

8 Manager.Flush; IdPessoaJuridica := Pessoa.Id; Manager.Free; Alguma diferença em relação à listagem 6? Nenhuma. A única diferença é que estamos lidando com uma outra classe, e portanto temos propriedades diferentes no caso, a propriedade CNPJ. O Aurelius se encarregará de fazer todos os SQL s necessários. No caso, ele irá executar um INSERT na tabela TBL_PESSOA, salvando os campos nome, cidade e telefone, obter o Id dessa tabela, e fazer um INSERT na tabela TBL_PESSOAJURIDICA, salvando o campo cnpj e também o Id gerado, pra definir a chave estrangeira com a tabela TBL_PESSOA. O interessante dessa abordagem é que na hora de desenvolver a aplicação, tudo fica mais fácil podemos organizar as classes e objetos de acordo com nossa lógica de negócio e toda a geração complexa de SQL s fica a cargo do framework. Associações Todo banco de dados tem relacionamentos e assim também devemos ter nas classes. Como cada classe corresponde (geralmente) a uma tabela, os relacionamentos são definidos justamente através de propriedades cujo tipo são classes. Observe a classe definida e mapeada na listagem 10: Listagem 10 Classes com associações [Automapping] TNotaFiscal = class private FId: integer; FPessoa: TPessoa; FData: TDateTime; FItens: TList<TItemNota>; constructor Create; destructor Destroy; override; property Id: integer read FId; property Pessoa: TPessoa read FPessoa write FPessoa; property Data: TDateTime read FData write FData; property Itens: TList<TItemNota> read FItemNota write FItemNota; A classe TNotaFiscal será mapeada pra uma tabela NotaFiscal. Note que essa classe tem uma propriedade do tipo TPessoa. Isso significa que a tabela NotaFiscal terá uma chave estrangeira pra tabela Pessoa (relacionamento muitos-pra-um). E também há uma lista de itens (classe TitemNota, que omitimos na listagem). O Aurelius irá criar uma tabela ItemNota e irá relacionar com a tabela NotaFiscal (uma nota pode ter muitos itens).

9 É interessante lembrar também que, como a nota fiscal está relacionada com uma classe TPessoa, podese utilizar qualquer objeto do tipo TPessoa, e isso inclui objetos do tipo TPessoa Juridica ou TPessoaFisica. A listagem 11 mostra como seria o salvamento de uma nota fiscal: Listagem 11 Salvando objetos com associações Pessoa: TPessoa; Nota: TNotaFiscal; ItemNota: TItemNota; Manager: TObjectManager; Manager := TObjectManager.Create(Conexao); Nota := TNotaFiscal.Create; Nota.Data := Date; Nota.Pessoa := Manager.Find<TPessoa>(IdPessoaJuridica.Id); ItemNota := TItemNota.Create; ItemNota.Produto := 'Martelo'; ItemNota.Valor := 10; Nota.Itens.Add(ItemNota); Manager.Save(Nota); Manager.Flush; Manager.Free; Pesquisas (Queries) Finalmente, após sal e atualizar os objetos, o que se precisa é uma forma de encontrá-los no banco. O Aurelius fornece uma API pra realizar consultas. É semelhante ao uso de comandos SQL você define os critérios de busca, filtros, ordenação, agrupamento, etc.. A Listagem 12 mostra um exemplo de consulta. Listagem 12 Executando uma consulta Manager: TObjectManager; Notas: TObjectList<TNotaFiscal>; Manager := TObjectManager.Create(Conexao); Notas := Manager.CreateCriteria<TNotaFiscal>.CreateAlias('Pessoa', 'p').where(tlinq.greaterthan('data', EncodeDate(2010, 1, 1)) and (TLinq.Like('p.Cidade', '%do Sul%'))).AddOrder(TOrder.Asc('Data'))

10 .List; // use a lista Notas como quiser // por exemplo, for Nota in Notas do... Notas.Free; Manager.Free; No exemplo da listagem 12, estamos buscando todas as notas fiscais cuja data seja maior que 01/01/2010 e também onde o nome da cidade da pessoa relacionada à nota contenha o texto do Sul. Solicitamos também que as notas sejam trazidas ordenadas por data. Podemos verificar duas coisas: primeiro, é possível fazer pesquisas pelas associações (assim como faríamos usando SQL com LEFT ou INNER JOIN). Segundo, a herança também tem o seu papel aqui. Como a nota fiscal pode estar relacionada a pessoa, pessoa jurídica ou pessoa física, a busca também deve seguir esse critério. Portanto, o Aurelius irá executar um SQL que irá fazer a busca nas três tabelas, e retornará todas as notas que atendem ao critério estabelecido, sejam pessoas jurídicas ou físicas. Demais recursos Vale lembrar que existem vários outros recursos: - Propriedades Nullable: Você pode definir propriedades como Nullable (que recebem valores null). - Carga tardia (lazy-loading): Ao carregar um objeto com associações (NotaFiscal.Pessoa por exemplo), pode-se configurar a propriedade Pessoa de modo que o Aurelius só busque os dados da pessoa quando realmente essa propriedade for acessada. - Campos Blob: pode-se usar campos blob (binário, texto) e também definir uma carga tardia pra eles (só trazer o conteúdo do campo quando necessário). - Outros tipos de Id: além do tipo integer, pode-se usar outros tipos de chave primária como string e data, bem como chaves compostas (apesar de não ser uma boa prática!) - Queries complexas: pode-se definir queries com projections (expressões, campos calculados), agrupamentos (Sum, Group By) e mesmo setar diretamente a SQL de partes da query, para casos mais avançados. Conclusão O objetivo desse artigo foi fazer uma introdução ao mapeamento objeto-relacional, especialmente usando a framework TMS Aurelius. Vários outros assuntos podem ser discutidos e apresentados, no que

11 se refere a construirs aplicações usando conceitos objeto-relacional, mas esses tópicos estão fora do escopo desse artigo. Espero que tenha sido interessante e que tenha conseguido apresentar uma forma diferente de se construir aplicações de banco de dados utilizando o Delphi. Autor Wagner Rafael Landgraf, 35, é formado em Engenharia Eletrônica e Mestre em Informática Industrial pela Universidade Federal Tecnológica do Paraná. Atualmente Gerente de Produtos da TMS Software ( trabalha com Delphi desde sua primeira versão em 1995, e é responsável por produtos como TMS Scripter Studio, TMS Diagram Studio, TMS Data Modeler e TMS Aurelius.