Inicio Automatico Transacciones

  • Uploaded by: Esteban
  • 0
  • 0
  • May 2020
  • PDF

This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA


Overview

Download & View Inicio Automatico Transacciones as PDF for free.

More details

  • Words: 973
  • Pages: 4
Inicio Automático de Transacciones en C# Por Lic. Esteban Calabria Fecha: 4 de Junio del 209 Resumen Veremos como interceptar llamadas a métodos de una capa de servicios en C# para implementar funcionalidad común, como el manejo de logs y las transacciones contra la base de datos. Tags AOP, C#, ContextBoundObject. ContextAttribute, Attribute, IMessageSink, IMessage, IMethodMessage Si nuestra aplicación posee un Service Layer[1], es probable que repitamos tareas en varios servicios. Por ejemplo, el manejo de las transacciones de la base de datos y el registro de la invocación del servicio en un log. Dichas operaciones llevan a tener código duplicado en distintos servicios. Veremos una forma de evitar dicha duplicidad aplicando algunos conceptos de AOP en C#. Supondremos un servicio para actualizar clientes que recibe un DTO [2] con la información que se desea actualizar, podemos tener algo de la siguiente manera: public class ServicioCliente

{ public static void ActualizarCliente( ClienteDto cliente) { Loguear Invocacion Servicio Iniciar Transaccion Con La Base (Start Transaction) try { //Actualizo los datos del cliente y toco varias tablas Ejecutar Servicio Hacer commit de la transaccion (Commit) } catch { Hacer rollback de la transaccion (Rollback) } finally { Finalizar Transaccion } } }

Ya teniendo tres o cuatro servicios que se ejecuten dentro de una transacción podemos notar que existen varias lineas de código que tienen que ver con el log y el manejo de transacciones que se repetirán y nos llevaran a cometer el pecado tener código duplicado. Utilizar un template method para reducir las líneas de código duplicadas no parece ser una solución que podamos aplicar en este caso. Tendremos que optar otra estrategia.

Es aquí donde utilizar algunas ideas de la programación orientada a aspectos (AOP) puede resultarnos de utilidad: tener un aspecto que se encargue de la funcionalidad común. Queremos lograr que al invocar un método de un servicio automáticamente se registre dica invocación en el log y, si se le indica explicictamente, manejar una transaccion contra la base de datos. Para implementarlo utilizaremos la infraestructura Remoting del framework de .Net. Internamente estaremos utilizando el patrón proxy[3]. De modo que cada vez que instanciemos un objeto se estara creando en forma transparente un proxy al mismo. Si queremos que al instanciar un objeto se genere automáticamente un proxy al mismo, debemos heredarlo de la clase ContextBoundObject. De hecho si inspeccionamos en el Visual Studio cualquier objeto que herede de ContextBoundObject vamos a ver que su tipo corresponde a {System.Runtime.Remoting.Proxies.__TransparentProxy}. El primer paso de nuestra implementación será indicar que métodos deben ejecutarse dentro de una transacción. Para ello los decoraremos mediante el atributo que se verá asi: [AttributeUsage(AttributeTargets.Method)] public class TransactionAttribute : Attribute { }

Luego codificaremos la clase ServiceMessageSink que sera la responsable de interceptar todos los mensajes (invocaciones a metodos en nuestro caso) que se le envíen a nuestro servicios. Para poder implementar lo que deseamos haremos que esta clase implemente la interfaz IMessageSink que nos permitirá acoplarnos al mecanismo que nos provee el framework para interceptar la llamada. Según la documentacion de .NET [5] la llamada a un método que se realiza a través de un proxy atraviesa una cadena enlazada de objetos que implementan la interfaz IMessageSink antes de llegar al objeto real. El mensaje se encapsula en un objeto del tipo IMessage y en particular nos interesan aquellos que sean del tipo IMethodMessage. Esta ultima interfaz nos proveera una forma de saber el nombre del método y los atributos que lo decoran mediante reflection. La clase nos quedara de la siguiente manera. class ServiceMessageSink : IMessageSink { private IMessageSink nextSink = null; public ServiceMessageSink(IMessageSink next) { this.nextSink = next; } #region IMessageSink Members public IMessageCtrl AsyncProcessMessage(IMessage msg, IMessageSink replySink) { throw new NotImplementedException(); }

public IMessageSink NextSink { get { return this.nextSink; } } public IMessage SyncProcessMessage(IMessage msg) { IMethodMessage methodMessage = msg as IMethodMessage; if (methodMessage != null) { Loguear Invocacion Servicio } if ((methodMessage != null) && (StartsTransaction(methodMessage))) { Inicio Transaccion try { //Invoco al método IMessage m = this.nextSink.SyncProcessMessage(msg); Commit de la transaccio return m; } catch (System.Exception e) { Rollback de la transaccio throw; } finally { Finalizo la transaccio } } return this.nextSink.SyncProcessMessage(msg); } private static bool StartsTransaction(IMethodMessage methodMessage) { bool bStartsTransaction = (Attribute.GetCustomAttribute(methodMessage.MethodBase, typeof(TransactionAttribute)) != null); return bStartsTransaction; } #endregion }

El método SyncProcessMessage es aquel que interceptará la llamada y donde codificaremos toda la logica común a todos los servicios. En particular : private static bool StartsTransaction(IMethodMessage methodMessage)

Se fijará si el metodo que invocamos esta decorado con el atributo Transaction que vimos anteriormente.

Para que esto funcione primero debemos declarar otro atributo llamado TransactionAwareService para decorar a aquellas clases cuyos métodos serán interceptados. Deberá heredar de ContextAttribute e implementará la interfaz IContextObjectSink que nos demandará completar el método GetObjectSink para asociar la clase a la cual decora con el IMessageSink que acabamos de codificar. [AttributeUsage(AttributeTargets.Class)] public class TransactionAwareService : ContextAttribute, IContributeObjectSink { public TransactionAwareService() : base("Transaction") { } #region IContributeObjectSink Members public IMessageSink GetObjectSink(MarshalByRefObject obj, IMessageSink nextSink) { return new ServiceMessageSink(nextSink); } #endregion }

Por ultimos heredaremos todas nuestras clases que implementen servicios de una clase base. La llamaremos BaseService, decoraremos esa clase con el atributo TransactionAwareService y por último haremos heredar la misma de ContextBoundObject para utilizar el mecanismo de proxys transparentes que mencionamos anteriormente. La clase nos quedará así [TransactionAwareService] public class BaseService : ContextBoundObject { }

De esta forma logramos interceptar llamadas a los métodos de nuestros servicios de forma transparente y con pocas lineas de codigo utilizando las capacidades de remoting del framework. Logramos asi ahorrarnos unas cuantas lineas de código que de otra manera estarían condenada a ser repetidas en los distintos servicios. Si el día de mañana cambia algo relacionado con las transacciones y el loggin será un solo lugar el que haya que mantener. Referencias [1] http://martinfowler.com/eaaCatalog/serviceLayer.html [2] http://en.wikipedia.org/wiki/Data_Transfer_Object [3] http://es.wikipedia.org/wiki/Template_Method_(patrón_de_diseño) [4]http://en.wikipedia.org/wiki/Proxy_pattern [5]http://msdn.microsoft.com/en-us/library/system.runtime.remoting.messaging.imessagesink.aspx

Related Documents

Inicio
April 2020 28
Inicio
October 2019 39
Inicio
November 2019 44

More Documents from ""