Desenvolvendo AOP com Spring.NET Aprenda a desenvolver aspectos para encapsular implementações de arquitetura das implementações de negócio

Transcrição

1 [Web Boas Práticas Design Patterns Orientação a Objetos AOP Spring.NET] Desenvolvendo AOP com Spring.NET Aprenda a desenvolver aspectos para encapsular implementações de arquitetura das implementações de negócio Fábio Augusto Falavinha (fabio.falavinha@zbra.com.br) Arquiteto de Software pela ZBRA Solutions, atuando com as tecnologias.net/java. Bacharel em Ciência da Computação pela Faculdade Sumaré e pós-graduado em Gestão de Qualidade de Software pela faculdade Senac. Blog: fabiofalavinha.blogspot.com Do que trata o artigo O artigo fundamenta o paradigma Orientado a Aspecto abordando seus elementos e a implementação deste conceito utilizando o framework Spring.NET. Para que serve Para organizar o código orientado a objetos em comportamentos, de forma tal que facilite sua manutenção e flexibilidade. Em que situação o tema é útil Para centralizar operações comuns de infraestrutura, como por exemplo registro de Logs, controle de exceções, regras de permissão, garantindo sua execução de forma automática. Esses são conceitos chamados de crosscuting, pois podem atravessar todas as camadas lógicas de um software. Resumo do DevMan O uso do paradigma Orientado a Aspecto (AOP) complementa implementações no modelo orientado a objeto facilitando o desenvolvimento das aplicações, separando a implementação de regras de negócio de infra-estrutura. AOP traz mecanismos que interagem e controlam objetos em tempo de execução e compilação, abstraindo qualquer implementação que afetará o uso da aplicação horizontalmente. O corte horizontal na aplicação é feito quando funcionalidades genéricas que interagem diversas vezes no ciclo de vida dos objetos são candidatas a esta abstração por parte de um aspecto. O uso do paradigma Orientado a Objetos (OO) é incontestável pelo fato de termos muitas linguagens que implementam este conceito, em nosso caso.net C#. Não é fácil abstrair um modelo de objetos capaz de mapear suas operações através de conceitos como: herança, polimorfismo, condições por contrato, mas mesmo assim a orientação a objetos ajuda a expressar melhor o problema a ser resolvido. Existe apenas um ponto que não pode ser mapeado de uma forma simples e fácil com OO, é a modelagem do comportamento dos objetos.

2 Para modelar o comportamento de objetos utilizamos sempre um padrão de projeto, como Strategy, Command, Factory, enfim, uma série de alternativas nas quais não se consegue extrair a essência a partir de um modelo mais simples. Neste caso, podemos utilizar um complemento ao paradigma de objetos, que é o paradigma Orientado a Aspectos (AOP). AOP foca na modularização de uma aplicação em aspectos. Isto é, aspectos ficam observando o ciclo de vida e interações entre os objetos de um sistema via troca de mensagens, até que possam agir. A seguir vamos entender melhor o que é um aspecto. Para realizar uma implementação através da plataforma.net, utilizaremos o framework Spring.NET. Fundamentos de AOP Todo paradigma de programação novo traz novos fundamentos e definições. Portanto, AOP traz elementos importantes para o seu entendimento, são eles: Aspect - unidade de programação criada para capturar uma funcionalidade que corta (crosscut) a aplicação. Alguns exemplos de possíveis aspectos são: Controle de Log, Controle de Exceção, Persistência, Segurança, Transação. Os exemplos citados são aplicações simples em relação à arquitetura da aplicação, porém, deve-se modelar uma aplicação levando em consideração os comportamentos que interagem com várias classes de diferentes módulos da aplicação; Joinpoints - é um ponto de controle onde um ou mais aspectos realizarão interações com a aplicação. Um exemplo simples de Joinpoint é o Controle de Log. Este controle pode ser realizado através da invocação de qualquer método de negócio. Assim, os joinpoints serão identificados por todos os métodos públicos das classes de serviço; Pointcuts - é um conjunto de Joinpoints onde os Aspectos realizarão interações com a aplicação; Advice Code - é o comportamento de um Aspecto. Está relacionado ao Joinpoint para realizar uma operação de crosscutting. Os três principais comportamentos de um aspecto são: o Before - este comportamento é realizado antes do Joinpoint ser executado; o After - este comportamento é realizado após o Joinpoint ser executado; o Around - este comportamento é realizado antes e após o Joinpoint. Este advice code deve ter uma atenção especial, pois, em alguns frameworks e linguagens de implementação de AOP, este comportamento é realizado manualmente pelo programador. Muitas vezes a instrução (método) de execução do Joinpoint recebe o nome de Proceed(). Esta instrução deve ser executada manualmente após realizar um processamento anterior ao Joinpoint. Introduction - mecanismo de extensão que traz novas implementações de elementos ao código de uma aplicação. Este mecanismo traz flexibilidade para adicionar novas implementações a campos (fields) e métodos, sendo estes os elementos mais comuns. Em relação a métodos, o objetivo deste mecanismo é introduzir novas implementações (interfaces) a objetos (targets). Por exemplo, caso seja necessário realizar um Controle de Exceção de uma aplicação, basta utilizar este mecanismo, assim como uma tecnologia ou linguagem AOP para adicionar novas implementações de captura de exceção;

3 Weaving - é um programa que integra classes e aspectos em tempo de compilação ou tempo de execução, veja a Figura 1. Em tempo de compilação pode ser utilizado, por exemplo, o Gripper-Loom.NET (veja a sessão links), que é um compilador que cria de forma estática, antes da execução, aspectos e seus advices. Figura 1. Integração entre classes através de Weaver. Spring.NET AOP O framework Spring.NET AOP foi desenvolvido utilizando a linguagem.net C#. O framework suporta a interceptação de métodos, através da implementação via Proxy, que são gerados em tempo de execução usando as classes contidas no pacote System.Reflection.Emit, veja a Figura 2. Figura 2. Execução do método Execute() do objeto command via Proxy. A implementação dos conceitos AOP são representados por interfaces e classes que constituem o nome advisor, como padrão do framework Spring. Outro padrão que inclui o framework é a

4 implementação das definições realizadas pela organização AOP Alliance. Todas as interfaces e classes, implementadas para este padrão, seguem o pacote Spring.Aop como parte da API do framework. Nota do DevMan Uma classe proxy tem a finalidade de representar um outra classe. Isso faz com que a definição de seus métodos, seja exatamente como a classe que ela representa. Porém sua implementação não contém a lógica real, e sim, uma transferência para execução do objeto real. Dessa forma, é possível adicionar comportamentos extras para classes reais, sem necessariamente ter que alterá-las, visto que antes de executar a classe real, podemos incluir algum ajuste na classe proxy. Aplicando Aspectos Como vimos na Figura 2, quando construímos um objeto e aplicamos um proxy para controlar a execução de seus métodos, uma camada é criada de forma transparente para estabelecer o comportamento que deve-se ter por parte do objeto. Para mostrar a prática do que vimos até aqui, vou utilizar um projeto do tipo Console Application. Abra o Visual Studio 2010 e crie um novo projeto do tipo Console Application, ao projeto dê o nome de SemAOP e à solução DevMedia. Nele insira as classes exibidas na Listagem 1, separando cada uma em seu respectivo arquivo.cs. Listagem 1. Classes sem AOP public class Cliente public IList<OrdemPagamento> OrdensPagamento get; set; public bool RemoverCliente(int id) foreach (OrdemPagamento op in OrdensPagamento) if (!op.paga) throw new Exception( Cliente não pode ser excluído. ); return new ClienteDAO().Delete(id); public class OrdemPagamento public bool Paga get; set; public class ClienteDAO public bool Delete(int id) return true; public class OrdemPagamentoDAO public OrdemPagamento[] FindByClienteId(int clienteid) return new OrdemPagamento[] new OrdemPagamento() Paga = false ;

5 Na Listagem 1 podemos reparar o relacionamento entre a classe Cliente e Ordem de Pagamento, onde o Cliente conhece suas ordens de pagamento. As classes DAO apenas simulam um acesso a dados aqui. Podemos observar que Cliente contém um método RemoverCliente, onde antes de realizar a remoção do cliente em questão, faz uma verificação referente as ordens de pagamento não pagas. Do ponto de vista de objetos podemos implementar este comportamento desta maneira, ou seja, ao tentar remover um cliente do sistema, o objeto cliente verificará se suas ordens de pagamento estão pagas, pois não podemos excluir um cliente com ordens de pagamento não pagas. Porém, a Orientação a Objetos não foca na modelagem de comportamento dos objetos, apenas em estruturar de forma organizada conjunto de objetos que estarão interagindo (troca de mensagens) uns com os outros. Como falamos no começo do artigo, o paradigma Orientado a Aspecto completa o paradigma orientado a objetos garantindo a modelagem de comportamento entre os objetos. Voltando ao nosso exemplo, podemos aplicar este conceito de forma simples, criando um Aspecto para realizar a verificação das ordens de pagamento de um cliente. Para isso vamos adicionar um novo projeto do tipo Console Application à solução. Vamos chamar esse projeto de ComAOP. A primeria coisa a se fazer é adicionar uma referências aos assemblies Spring.Core e Spring.Aop, localizados na pasta se instalação do framework Spring.Net (veja onde baixá-lo na seção Links). Então copiamos para este novo projeto as classes anteriormente criadas (Cliente, ClienteDAO, OrdemPagamento e OrdemPagamentoDAO). Agora para criar o Aspecto adicionamos uma nova classe. Vejamos a Listagem 2. Listagem 2. Aspecto Ordem de Pagamento. public class RemoverClienteAspecto : IMethodInterceptor public object Invoke(IMethodInvocation invocation) int clienteid = (int)invocation.arguments[0]; Console.WriteLine("Recuperando ordens de pagamento do cliente [id=" + clienteid + "]..."); OrdemPagamento[] ops = new OrdemPagamentoDAO().FindByClienteId(clienteId); pagas..."); Console.WriteLine("Verificando ordens de pagamento não foreach (OrdemPagamento op in ops) if (!op.paga) throw new Exception("Cliente não pode ser removido."); Console.WriteLine("Não há ordens de pagamento NÃO PAGAS para o cliente, continuando a remoção do cliente."); return invocation.proceed();

6 Na Listagem 2 podemos observar a representação de um aspecto por parte da classe RemoverClienteAspecto. Esta classe encapsula o comportamento de verificação das ordens de pagamento que está sendo realiazada no método RemoverCliente da classe Cliente, porém temos algumas diferenças. O Aspecto neste caso é executado no momento que o método Cliente.RemoverCliente for chamado, assumindo o lugar do original. O método original é encapsulado dentro do parâmetro invocation do método Invoke. Assim, conseguimos obter o clienteid passado. E como o aspecto não está dentro da instância do objeto Cliente, é necessário carregarmos a lista de ordens de pagamento utilizando o OrdemPagamentoDAO. Então, se o cliente poder ser excluído, mandamos o Framework continuar com a execução do método original, através da chamada do método invocation.proceed(). Já que temos o Aspecto pronto podemos retirar do método original a verificação das ordens de pagamento, veja a Listagem 3. O tipo de implementação utilizada aqui é chamada de Around Advise. Listagem 3. Classe Cliente sem verificação da Ordem de Pagamento public interface ICliente IList<OrdemPagamento> OrdensPagamento get; set; bool RemoverCliente(int id); public class Cliente : ICliente public IList<OrdemPagamento> OrdensPagamento get; set; public bool RemoverCliente(int id) Console.WriteLine("Removendo cliente [id=" + id + "]..."); return new ClienteDAO().Delete(id); Para utilizamos efetivamente o Aspecto nossa classe Cliente necessita ter um contrato (interface), que será posteriormente utilizado na geração de um objeto proxy, por isso temos agora a interface ICliente. Conseguimos ter um código mais claro com a implementação de um Aspecto para controlar a remoção de clientes. Vamos configurar o framework Spring.NET para que possamos executar nosso exemplo. Isso será feito na classe Program, veja a Listagem 4. Listagem 4. Configuração programática do exemplo class Program static void Main(string[] args) ProxyFactory factory = new ProxyFactory(new Cliente()); factory.addadvisor(new DefaultPointcutAdvisor(new SdkRegularExpressionMethodPointcut("RemoverCliente"), new RemoverClienteAspecto())); ICliente cliente = (ICliente)factory.GetProxy(); try cliente.removercliente(1); catch (Exception cause) Console.WriteLine(cause);

7 Console.ReadKey(); Na Listagem 4 configuramos nosso exemplo de forma programática, utilizando a API do framework Spring.NET. Note que utilizamos duas classes novas do framework Spring, ProxyFactory e SdkRegularExpressionMethodPointcut. A primeira classe cria um proxy para o objeto Cliente, que foi passado como argumento do construtor da classe. A segunda classe representa um pointcut que verificará, em tempo de execução, a chama de métodos que serão filtrados pelo nome RemoverCliente, passado como argumento do construtor desta classe. Execute o programa e veja que as mensagens criadas dentro do Aspecto irão aparecer no console, inclusive a mensagem de exceção. Outra maneira de configurar aspectos utilizando o framework Spring.NET é através de XML. Adicione ao projeto um arquivo XML, lhe dê o nome de Exemplo-Context.xml e o configure como mostra a Listagem 5. Também é necessário acessar suas propriedades e ajustar sua propriedade Build Action para Embedded Resource. Listagem 5. Configuração via XML do exemplo: Exemplo-Context.xml <?xml version="1.0" encoding="utf-8"?> <objects xmlns=" <object id="removerclienteaspecto" type="spring.aop.support.regularexpressionmethodpointcutadvisor"> <property name="pattern" value="removercliente"/> <property name="advice"> <object type="comaop.removerclienteaspecto"/> </property> </object> <object id="cliente" type="spring.aop.framework.proxyfactoryobject"> <property name="target"> <object id="clientetarget" type="comaop.cliente"/> </property> <property name="interceptornames"> <list> <value>removerclienteaspecto</value> </list> </property> </object> </objects> A configuração via XML facilita a manutenção do código, permitindo que o código que vimos na Listagem 4, esteja escondido em um arquivo de configuração da aplicação. Para executar o nosso exemplo através dessa configuração é necessário alterar a classe Program, veja a Listagem 6. Listagem 6. Execução do exemplo e configuração via XML public class Program public static void Main(string[] args) ICliente cliente = (ICliente)ContextRegistry.GetContext()["cliente"]; try cliente.removercliente(1); catch (Exception cause)

8 Console.WriteLine(cause); Console.ReadKey(); Note que utilizando a configuração de objetos e aspectos via XML, conseguimos um código mais simples, facilitando seu entendimento. Na Listagem 6 utilizamos mais uma classe do framework Spring.NET, ContextRegistry. Esta classe procura na configuração da aplicação.net, via arquivo App.Config, a informação dos arquivos de contexto, como são chamados. Em nosso caso o arquivo de configuração do exemplo é Exemplo-Context.xml. Para configurar o framework Spring.NET através do arquivo de configuração App.Config é preciso primerio adicioná-lo ao projeto. Para isso clique com o botão direito do mouse sobre o projeto, escolha Add>New Item. Na janela que surge clique o item General e escolha Application Configuration File. Nele, inclua o exemplo da Listagem 7. Listagem 7. Configuração do arquivo App.Config <?xml version="1.0" encoding="utf-8"?> <configuration> <configsections> <sectiongroup name="spring"> <section name="context" type="spring.context.support.contexthandler, Spring.Core"/> </sectiongroup> </configsections> <appsettings /> <spring> <context> <resource uri="assembly://comaop/comaop/exemplo-context.xml" /> </context> </spring> </configuration> Declaramos uma sessão de nome spring que habilitará o contexto do framework Spring para carregar o arquivo de configuração do nosso exemplo, como destacado acima. Advice Code O framework Spring.NET disponibiliza quatro de tipos de implementações para advices: Around, Before, After e Throws. O exemplo com o advice Around foi demonstrado na sessão anterior. Veremos os restantes. Before Advice A implementação por parte do framework Spring.NET está na realização da interface Spring.Aop.IBeforeAdvice, como mostra o código a seguir. public class ExemploAspectoBefore : IBeforeAdvice public void Before(MethodInfo method, object[] args, object target) //Código de execução do aspecto.

9 Note que o código representa um aspecto que será aplicado antes da execução de um método. Este aspecto consumirá a execução e ao finalizar a execução de seu método Before, o método do objeto a que esse aspecto se aplica, target, será executado. After Advice A implementação por parte do framework Spring.NET está na realização da interface Spring.Aop.IAfterReturningAdvice, veja o código seguinte. public class ExemploAspectoAfter : IAfterReturningAdvice public void AfterReturning(object returnvalue, MethodInfo method, object[] args, object target) //Código de execução do aspecto. Note que o código representa um aspecto que será aplicado após a execução de um método. O retorno do método será atribuído ao argumento returnvalue, caso o método for Void, este valor será nulo. Throws Advice A implementação por parte do framework Spring.NET está na realização da interface Spring.Aop.IThrowsAdvice, veja o código. public class ExemploAspectoAfter : IThrowsAdvice public void AfterThrowing(Exception ex) //Código de execução do aspecto. Note que o código representa um aspecto que será aplicado quando for disparado uma exceção na execução de um método. Pode-se realizar o controle da exceção através de seu tipo base System.Exception ou pode-se informar no argumento do método AfterThrowing um tipo diferente, por exemplo System.InvalidOperationException. Conclusão AOP não é apenas uma tecnologia, e sim, um paradigma, uma forma de pensar. Facilita a modelagem e análise de comportamentos de objetos de uma aplicação. Abstrai de forma simples e coerente a relação dos objetos com a o meio externo (infraestrutura). Portanto, qualquer funcionalidade que tenha um comportamento genérico ao modelo de negócio é forte candidata ao uso de aspectos. Organizar uma aplicação através de aspectos compreende em separar objetos do modelo de negócio, de objetos do modelo de infraestrutura. O código fica limpo e de fácil manutenção, pois o encapsulamento destes dois módulos garante a coesão e aderência da arquitetura do software. Links Spring.NET

10 Gripper-LOOM.NET Blogs do autor Saiba Mais Artigo Java Magazine 70 Fundamentos de AOP para aplicações Java Fábio Augusto Falavinha