Transaction Scripts: Uma Forma mais Simples de Organizar Lógica de Domínio

Roberto Perillo (jrcperillo@yahoo.com.br) é bacharel em Ciência da Computação e está atualmente cursando mestrado no ITA, onde já concluiu o curso de especialização em Engenharia de Software. Trabalha com Java há mais de 5 anos, possui as certificações SCJP, SCWCD, SCJD e SCBCD, e é moderador no JavaRanch, onde participa ativamente dos fóruns. Já trabalhou com JEE em grandes empresas, como Avaya e IBM. Nesta última, foi co-fundador do time de inovação de ibm.com GWPS LA. Atualmente, trabalha na GSW Soluções Integradas como líder técnico de desenvolvimento OO e Senior Java Developer. Transaction Scripts: Uma Forma mais Simples de Organizar Lógica de Domínio Uma opção simples quando não é possível (ou necessário) utilizar um modelo de domínio Existem alguns padrões arquiteturais que objetivam organizar a lógica de domínio de aplicações, dois que se destacam são o Domain Model e o Transaction Script. O padrão Domain Model organiza a lógica de domínio através de um modelo de objetos rico e é indicado principalmente quando essa lógica é complexa. Entretanto, existem algumas situações nas quais um modelo de domínio não se aplica. Na maioria dessas situações, o padrão Transaction Script pode ser utilizado. Ele propõe uma abordagem mais procedural, mas que pode ser considerada mais adequada nesses casos. Neste artigo, o padrão Transaction Script é apresentado e é exemplificado como ele pode ser utilizado, e são ilustrados alguns benefícios que podem ser alcançados com a sua utilização. o excelente livro Patterns of Enterprise Application Architecture, Martin Fowler aborda alguns padrões de organização de lógica de domínio, sendo que os que mais se destacam por serem amplamente utilizados na indústria são o Domain Model e o Transaction Script. O Domain Model é uma excelente forma de organizar lógica de domínio, pois sugere uma estrutura que permite refletir efetivamente o modelo de domínio no código, utilizando assim todas as forças e benefícios que a orientação a objetos oferece. Consequentemente, o desenvolvimento se torna mais produtivo e o código fica mais fácil de manter e evoluir com o passar do tempo. O Domain Model é indicado principalmente quando a lógica de domínio é complexa. Entretanto, existem algumas situações em que o Domain Model não é o padrão mais indicado, como quando a lógica de domínio é simples, ou a equipe de desenvolvimento não possui a maturidade necessária em relação à orientação a objetos, por exemplo. Na maioria desses casos, o padrão Transaction Script, que é uma abordagem mais procedural, pode ser considerado o padrão mais apropriado. O objetivo deste artigo é introduzir o padrão Transaction Script como uma forma mais simples de se organizar lógica de domínio e está organizado da seguinte forma: primeiramente, é apresentada uma discussão sobre design orientado a objetos versus design procedural. 16

Em seguida, é apresentado o padrão Transaction Script, no qual são apresentadas considerações sobre organização em camadas da arquitetura de aplicações e uma breve discussão sobre quando o padrão Transaction Script pode ser o padrão de organização de lógica de domínio mais apropriado a ser aplicado. Logo após, é apresentado um exemplo de aplicação do padrão Transaction Script e é mostrado como um projeto que o utiliza normalmente é organizado. Em seguida, é apresentado um exemplo de como ele pode ser utilizado em uma aplicação real. E, finalmente, são apresentadas as considerações finais, finalizando o presente trabalho. Apresentação Negócios Persistência Base de Dados Figura 1. Organização da arquitetura tradicional de quatro camadas. Para Saber Mais Consulte o artigo Domain Model: Uma Forma Mais Eficiente de Construir Aplicações Enterprise, publicado na edição 42 da revista MundoJ, para ter uma visão mais detalhada sobre o padrão Domain Model. Design Orientado a Objetos Vs. Design Procedural Existem algumas formas de organizar a arquitetura de uma aplicação orientada a objetos, mas a indústria convergiu para a arquitetura em camadas. O grande benefício da organização em camadas é que cada camada pode ser projetada especificamente para cada interesse, promovendo assim um design mais coeso. A essência dessa organização é que elementos das camadas superiores comuniquem-se somente entre si ou que sejam auxiliados pelas camadas inferiores. As camadas inferiores não devem saber que as camadas superiores existem, para que haja mais flexibilidade e coesão e para que o acoplamento seja baixo. Em algumas situações, pode ser necessário que uma camada de nível inferior se comunique com uma camada de nível superior, por exemplo, em um cenário no qual clientes estão conectados a um servidor e a camada de domínio precisa comunicar a todos os clientes que os dados sendo exibidos foram alterados por um determinado cliente. Nesses casos, pode-se utilizar mecanismos de callback ou o padrão Observer. No excelente livro EJB 3 In Action, os autores abordam um estilo de arquitetura chamado arquitetura tradicional de quatro camadas, que é bastante conhecido entre designers de aplicações enterprise. As quatro camadas que compõem este estilo de arquitetura são: camada de apresentação, camada de negócios, camada de persistência e camada de banco de dados, como é mostrado na figura 1. A camada de apresentação é responsável por lidar com interesses de UI (User Interface), como exibir mensagens visuais para o usuário, habilitar ou desativar campos-texto, lidar com botões do tipo radio etc. Esta camada deve conter somente lógica de UI, e não propriamente de negócios, que deve se concentrar somente na camada de negócios (ou domínio). Essa camada representa o coração deste estilo de arquitetura e é responsável por concentrar todas as regras de negócio implementadas pela aplicação. Esta camada não recupera ou persiste informações no banco de dados; ao invés disso, todas as operações de banco de dados são intermediadas pela camada de persistência, que é uma abstração orientada a objetos sobre a camada de banco de dados. Esta camada não deve conter regras de negócio, e deve burramente obedecer a todas as requisições da camada de negócio. Assim, a camada de negócios/domínio concentra todas as regras de negócio implementadas em uma aplicação. Para a organização dos componentes dessa camada, existem alguns padrões de organização de lógica de domínio que podem ser utilizados, sendo que os mais utilizados na indústria são o Domain Model e o Transaction Script. O Domain Model sugere implementar um modelo de domínio através de um modelo de objetos rico que utiliza plenamente todas as forças que a orientação a objetos oferece, e é adequado principalmente quando a lógica de domínio é complexa. Ele permite refletir efetivamente o modelo de domínio no código, que é o princípio do Model-Driven Design. Basear a implementação do código em um modelo proporciona alguns benefícios. A conexão entre o modelo e o código permite verificar se a análise feita no modelo se aplica no código criado, facilitando assim a contínua evolução e manutenção do modelo e do software criado. Entretanto, existem algumas situações em que utilizar o Domain Model pode não ser o mais adequado. Basear a implementação em um modelo é uma tarefa difícil que exige experiência em modelagem de sistemas e orientação a objetos. Em algumas situações, não é necessário basear a implementação em um modelo, pelo fato de que a lógica é muito simples (como CRUDs, por exemplo). Para esses casos, o padrão Transaction Script pode ser utilizado. Ele propõe organizar a lógica de domínio de uma forma mais procedural, porém simples e que existe especificamente para esses casos. O Padrão Transaction Script O padrão Transaction Script organiza a lógica de domínio em um conjunto de métodos, em que cada método lida com uma requisição da camada de apresentação e organiza a lógica de negócios implementada pela aplicação. Idealmente, os transaction scripts devem ser agrupados em classes que lidam com tarefas similares. Essas classes conterão somente os transaction scripts, e assim possuirão somente comportamento. Por exemplo, em um cadastro de funcionários, poderia existir uma classe chamada TransactionScriptsCadastroFuncionarios que conteria métodos como cadastrarfuncionario(funcionario), alterarda dosfuncionario(funcionario) etc. Martin Fowler deu esse nome a esse padrão porque, na maioria dos casos, haverá um transaction script por transação de banco de dados. Logo, na maioria dos casos, o tratamento de cada requisição da camada de apresentação implica em uma transação, ou um conjunto atômico de operações. Em um projeto usual, os Transaction Scripts efetuam computações e podem lidar diretamente com o banco de dados. No entanto, uma forma mais eficiente é utilizar DAOs para encapsular o acesso a dados. Cada Transaction Script utiliza objetos burros que existem somente 17

para transferir dados entre as camadas (os chamados DTOs). Dessa forma, dada uma requisição da camada de apresentação, um Transaction Script preenche ou recebe um DTO, utiliza seus dados para efetuar computações, podendo passá-lo para um DAO caso o método lide com persistência, e pode devolver um DTO para a camada de apresentação. Um modelo de domínio que contém somente DTOs que só existem para a transferência de dados entre as camadas e não possuem nenhuma inteligência é chamado de modelo de domínio anêmico. A utilização do padrão Transaction Script é bastante simples, pois sua aplicação é direta e não é preciso se preocupar em identificar classes e atribuir a elas responsabilidades, como acontece quando o padrão Domain Model é utilizado. Assim, não é necessário possuir muita experiência com orientação a objetos. Ao mesmo tempo, a simplicidade desse padrão também é uma limitação. Pelo fato de que transaction scripts são rotinas que tratam requisições da camada de apresentação, o código pode ficar difícil de manter e entender. Além disso, é bastante comum ter código duplicado quando esse padrão é utilizado. Por isso, sua utilização é indicada principalmente quando a lógica de domínio for simples. Para Saber Mais No artigo Desmistificando a Certificação SCJD: a certificação que merece mais atenção da comunidade Java, publicado na edição 40 da revista MundoJ, é apresentada uma forma de resolver a atribuição dessa certificação utilizando o padrão Transaction Script. Um exemplo de aplicação do Padrão Transaction Script da aplicação é efetuar reservas de quartos de hotel para clientes online. Embora seja perfeitamente válido aplicar na mesma aplicação o Domain Model (para lidar com a lógica de domínio complexa) e o Transaction Script (para lidar com a lógica de domínio simples) em conjunto, a lógica de domínio nesse caso é simples; logo, somente o padrão Transaction Script se faz necessário.o modelo apresentado na figura 2 corresponde a um modelo de domínio anêmico, pois não contém nenhuma inteligência. As classes que o compõem existem somente para a transferência de dados entre as camadas, e toda a inteligência da aplicação é concentrada nos transactions scripts. Na Listagem 1 é apresentada a classe que contém o transaction script que reserva o quarto de hotel para um determinado cliente. Caso novas funcionalidades referentes a reservas precisassem ser adicionadas, elas seriam naturalmente adicionadas à classe apresentada na Listagem 1. Listagem 1. Classe que contém o transaction script que efetua a reserva do quarto de hotel. package br.com.mj.hotel.business; // imports omitidos... public class TransactionScriptsReservasQuartosDefault implements TransactionScriptsReservasQuartos { private DaoReservas daoreservas; private DaoClientes daoclientes; private DaoQuartos daoquartos; public TransactionScriptsReservasQuartosDefault( DaoReservas daoreservas, DaoClientes daoclientes, DaoQuartos daoquartos) { super(); this.daoreservas = daoreservas; this.daoclientes = daoclientes; this.daoquartos = daoquartos; public void reservarquarto(int idcliente, int numeroquarto, Date inicioreserva, Date fimreserva) throws QuartoJaReservadoException { Reserva reserva = daoreservas.find(numeroquarto, inicioreserva, fimreserva); if (reserva!= null) { String mensagem = Este quarto já contem uma reserva + no período indicado. ; throw new QuartoJaReservadoException(mensagem); Cliente cliente = daoclientes.find(idcliente); Quarto quarto = daoquartos.find(numeroquarto); 18 Figura 2. Modelo de domínio utilizado na aplicação de reservas de quartos de hotel. Para exemplificar a utilização do padrão Transaction Script, consideremos o exemplo apresentado a seguir. Pelo fato de que cada Transaction Script lida com uma requisição da camada de apresentação, não importa se a aplicação é web ou desktop, mas o exemplo proposto pelo presente artigo apresenta uma aplicação web. O objetivo Periodo periodo = new Periodo(inicioReserva, fimreserva); Reserva novareserva = new Reserva(); novareserva.setcliente(cliente); novareserva.setquarto(quarto); novareserva.setperiodo(periodo); daoreservas.save(novareserva);

Por exemplo, supondo-se que as informações de pagamento seriam adicionadas somente no momento do check-in ou check-out, o método reservarquarto efetuaria a reserva com as informações de pagamento nulas, e poderiam ser adicionados mais dois métodos à interface TransactionScriptsReservasQuartos, checkin e checkout, que receberiam as informações de pagamento e atualizaram corretamente o registro da reserva. Assim, transaction scripts são métodos que compõem classes de negócios de granularidade grossa e cada transaction script lida com uma requisição da camada de apresentação. Esse estilo pode ser considerado procedural, pois, nesse caso, a classe de negócios possui interesses que deveriam estar distribuídos em classes do modelo de domínio implementado, onde cada classe cuidaria de interesses específicos. Um transaction script pode não ser um método de uma classe Java; pode ser uma rotina de um script CGI, por exemplo. Se existe uma rotina que lida com uma requisição da camada de apresentação e implementa regras de negócio, sendo que essa rotina cuida de interesses que deveriam estar distribuídos em classes (ou outras estruturas), em que cada classe (ou estrutura) cuidaria somente dos interesses que fossem de sua competência, então essa rotina pode ser considerada um transaction script. Em uma aula da disciplina de Fundamentos de Engenharia de Software do curso de mestrado do ITA, o professor Clovis Torres Fernandes falou sobre atribuição de responsabilidades. Uma responsabilidade é tudo que uma classe sabe ou faz. No exemplo apresentado acima, a classe TransactionScriptsReservasQuartosDefault efetua a reserva de um quarto para um cliente. Caso o Domain Model estivesse sendo utilizado, essa responsabilidade seria da classe Quarto (que seria uma entidade) e seria invocada a partir de uma classe de serviços. As classes seriam mais coesas e de granularidade menor, e cada classe do modelo teria somente as responsabilidades que fossem de sua competência. Utilizando os Transaction Scripts Para exemplificar a utilização do transaction script proposto pelo presente artigo, consideremos sua utilização a partir de um Controller (Servlet), que recebe requisições da tela de reservas de quartos de hotel. Idealmente, poderia ser construído um Front Controller (padrão do catálogo Core J2EE Patterns), que receberia todas as requisições da aplicação e delegaria a descoberta do componente responsável pelo tratamento de cada requisição a um Application Controller (outro padrão do catálogo Core J2EE Patterns), que também seria responsável por direcionar o usuário ao componente de visualização correto, mas como o exemplo proposto aborda uma aplicação simples, tal modelagem não se faz necessária. Embora atualmente não seja mais tão comum a utilização direta desses padrões, pode-se observar sua utilização em vários frameworks que objetivam controlar aplicações web. Por exemplo, o padrão Application Controller pode ser observado no framework Struts, que utiliza mapeamento declarativo para facilitar o gerenciamento de ações e componentes de visualização. Para promover flexibilidade, a aplicação pode se utilizar de injeção de dependência via construtor, que é uma das três formas possíveis de injeção de dependência. Para arranjar os objetos no momento em que a aplicação é iniciada, o framework Spring pode ser utilizado. Ele também pode ser utilizado para tornar cada transaction script transacional, para que as operações realizadas por eles sejam processadas de forma atômica. Nesse caso, deve-se definir um arquivo XML e definir algumas configurações no web.xml da aplicação, para que objetos sejam corretamente instanciados e arranjados pelo Spring quando a aplicação for iniciada. Na Listagem 2, é apresentado o Servlet que corresponde ao Controller que recebe as requisições da tela de reservas de quartos de hotel e, na Listagem 3, é apresentado o XML consumido pelo Spring no momento em que a aplicação é iniciada. Listagem 2. Controller que recebe as requisições de reservas de quartos de hotel. package br.com.mj.hotel.controllers; // imports omitidos... public class ControllerReservasQuartos extends HttpServlet { @Override public void dopost(httpservletrequest request, HttpServletResponse response) throws ServletException, IOException { String xmlspring = getservletconfig().getinitparameter( xmlspring ); ApplicationContext context = new ClassPathXmlApplicationContext(xmlSpring); TransactionScriptsReservasQuartos scripts = (TransactionScriptsReservasQuartos) context.getbean( transactionscriptsreservasquartos ); int idcliente = Integer.parseInt(request.getParameter( idcliente )); int numeroquarto = Integer.parseInt(request.getParameter( numeroquarto )); Date inicioreserva = converterparadata(request.getparameter( inicioreserva )); Date fimreserva = converterparadata(request try {.getparameter( fimreserva )); scripts.reservarquarto(idcliente, numeroquarto, inicioreserva, fimreserva); RequestDispatcher dispatcher = request.getrequestdispatcher( /SucessoReserva.jsp ); dispatcher.forward(request, response); catch (QuartoJaReservadoException exception) { request.setattribute( mensagem, exception.getmessage()); RequestDispatcher dispatcher = request.getrequestdispatcher( /QuartoJaReservado.jsp ); dispatcher.forward(request, response); private Date converterparadata(string data) {... 19

20 Listagem 3. XML de arranjo de objetos consumido pelo Spring. <?xml version= 1.0 encoding= UTF-8?> <beans...> <bean id="sessionfactory" class="org.springframework.orm.hibernate3.localsessionfactorybean"> <property name="configlocation"> <value>classpath: hibernate.cfg.xml</value> <bean id="hibernatetemplate" class="org.springframework.orm.hibernate3.hibernatetemplate"> <property name="sessionfactory" ref="sessionfactory" /> <bean id="daoreservas" class="br.com.mj.hotel.persistence.daoreservasdefault"> <bean id="daoclientes" class="br.com.mj.hotel.persistence.daoclientesdefault"> <bean id="daoquartos" class="br.com.mj.hotel.persistence.daoquartosdefault"> <bean id="transactionscriptsreservasquartos" class="br.com.mj.hotel.business.transactionscriptsreservasquartosdefault"> <constructor-arg ref="daoreservas" /> <constructor-arg ref="daoclientes" /> <constructor-arg ref="daoquartos" /> <bean id="transactionmanager" class="org.springframework.orm.hibernate3.hibernatetransactionmanager"> <property name="sessionfactory" ref="sessionfactory" /> <bean id="matchallmethods" class="org.springframework.transaction.interceptor.matchalwaystran sactionattributesource" /> <bean id="transactioninterceptor" class="org.springframework.transaction.interceptor.transactioninterceptor"> <property name="transactionmanager"> <ref bean="transactionmanager" /> <property name="transactionattributesource"> <ref bean="matchallmethods" /> <bean id="transactionproxycreator" class="org.springframework.aop.framework.autoproxy. BeanNameAutoProxyCreator"> <property name="beannames"> <list> <idref bean="transactionscriptsreservasquartos" /> </list> <property name="interceptornames"> <list> <idref bean="transactioninterceptor" /> </list> </beans> A modelagem proposta pelo presente artigo também atende ao padrão MVC, pois o Controller recebe a requisição do componente de visualização, delega seu tratamento ao componente de negócios apropriado (no caso, uma instância da classe TransactionScriptsReservasQuartosDefault) e despacha os objetos HttpServletRequest e HttpServletResponse ao componente de visualização que será exibido ao usuário como resposta à requisição feita. Do ponto de vista da arquitetura tradicional em quatro camadas, o Controller também faz parte da camada de apresentação. Nesse caso, como a criação do Servlet não é controlada pelo Spring, não é possível se utilizar de injeção de dependência. Por isso, o bean de id transactionscriptsreservasquartos, criado pelo Spring, é recuperado no Servlet através do objeto de contexto do Spring. Os parâmetros da requisição são então recuperados e passados ao objeto da classe TransactionScriptsReservasQuartosDefault que contém a lógica de negócios de reserva de quartos. Esse objeto conta com a colaboração de DAOs para recuperar e persistir informações no banco de dados. Caso fosse uma aplicação Swing, o objeto da classe TransactionScriptsReservas- QuartosDefault poderia ser, por exemplo, injetado em um objeto ActionListener através de seu construtor e utilizado para tratar ações a partir do clique do usuário em um botão. Considerações finais Neste artigo, foi apresentado o padrão Transaction Script, que é um padrão de organização de lógica de domínio indicado quando não é possível (ou necessário) utilizar um modelo de domínio. A chave desse padrão é a simplicidade e sua utilização é indicada principalmente quando a lógica de domínio é simples. Os principais padrões de organização de lógica de domínio são o Domain Model e o Transaction Script. O Domain Model, apesar de ser uma excelente forma de organizar a lógica de domínio através de um modelo de objetos rico, requer experiência em modelagem OO e é indicado quando a lógica de domínio é complexa. Em contrapartida, o Transaction Script sugere uma forma simples de lidar com a lógica de domínio, em que as classes contêm rotinas que tratam requisições da camada de apresentação. Deve-se avaliar com cuidado quando sua aplicação é apropriada, pois esse padrão é a abordagem procedural da orientação a objetos e tende a levar a duplicação de código Referências FOWLER, Martin. Patterns of Enterprise Application Architecture. Boston: Addison- Wesley Professional, 2002. PANDA, Debu; RAHMAN, Reza; LANE, Derek. EJB 3 In Action. Greenwich, CT: Manning Publ., 2007. PERILLO, Roberto. Desmistificando a Certificação SCJD: A Certificação Que Merece Mais Atenção da Comunidade Java. Revista MundoJ, Edição 40, 2010. PERILLO, Roberto. Domain Model: Uma Forma Mais Eficiente de Construir Aplicações Enterprise. Revista MundoJ, Edição 42, 2010.