Hola amigos, hace mucho que no hacía un post en la comunidad y esta vez me animé a tocar este tema, el ejemplo que les mostraré será básico y poco a poco podremos poner unos más avanzados.

La ventaja de tener una comunidad enteramente en español dedicado a CSLA.NET ha dado mucho que hablar y como no los adeptos son cada vez más es por eso mi intención de difundir temas sobre esta herramienta que cada día nos ayuda en nuestras labores cotidianas.

Para empezar con este post se requiere lo siguiente:

  • CSLA.NET 3.8.3
  • C# 3.0
  • Microsoft SQL Server 2005/2008 Express Edition
  • Visual Studio 2008/2010 Standar Edition

Primero, tenemos nuestro modelo de datos:

image

Como se puede apreciar en la imagen, ya he modelado mi Base de Datos y las he “mapeado” como clases con el diseñador de Linq to SQL.

En la clase Clientes definimos nuestras propiedades que se asemejen a lo mapeado a la tabla Cliente.

image

Verán que uso las nuevas características de CSLA para la declaración de propiedades, usando las expresiones Lambda para establecer un “Nombre amigable” como se puede apreciar en las propiedades Nombres y Apellidos.

Ahora bien, el objetivo de este post es centrarnos en conectarnos a la BD de SQL Server con Linq. Por lo tanto usaremos una clase llamada ContextManager para usarla como “wrapper”, pues si intentamos usar directamente sentencias Linq nos saldrá un mensaje indicando que la clase DataContext no está marcada como Serializable, esto se debe a que los objetos de negocio basados en CSLA “viajan” del servidor al cliente con la tecnología de comunicación remota que escojamos (.NET Remoting, WCF, Enterprise Services, etc.).

CSLA.NET contiene 4 clases muy útiles que nos permiten usar las tecnologías más conocidas para acceso a datos de Microsoft:

ADO.NET – ConnectionManager
Linq to SQL – ContextManager
Entity Framework – ObjectContextManager
ADO.NET Data Services – DataServiceContextManager

Todas estas clases se encuentran en el Namespace Csla.Data.

Para usar otros frameworks de acceso a datos se puede hacer uso del ObjectFactory, pero eso ya lo veremos en otro post quizás.

Bien, sin ir más lejos implementemos los 3 métodos DataPortal_XYZ. Para este caso he creado una clase parcial a la clase Cliente (la que se encarga de “mapear” la tabla Clientes) que contenga un método que me permita buscar un registro en base a su ID.

image

Este método me debe devolver un objeto Cliente, como primer parámetro obtengo mi clase DataContext, seguido del Id del Cliente que es un String, podrán notar que uso la función SingleOrDefault para que me devuelva un objeto vacío (null) en caso de no encontrar el registro. Entonces en el método DataPortal_Fetch escribimos el siguiente código:

image

Aquí hay algo que quiero resaltar de esta versión de CSLA.NET que trae consigo una clase llamada SingleCriteria, el cual nos pide como parámetro genérico la clase en cuestión y el tipo de dato de nuestra llave que nos permitirá distinguir un registro de otro, ya que en otras versiones anteriores nosotros teníamos que crear una clase embebida para buscar un registro en particular, claro que si usamos llaves compuestas esto no nos sirve (aunque en mi opinión personal no soy partidario de las llaves compuestas).

Bueno, la clase ContextManager contiene un parámetro genérico el cual recibirá nuestro DataContext, seguidamente de un método que devuelve un objeto ContextManager que nos permitirá interactuar con nuestra base de datos, no olviden jamás usar la instrucción using de C# (Using en VB) para liberar recursos administrados al final de la consulta.

image

Para el caso del DataPortal_Insert, realizamos el mismo paso del ContextManager, como se puede apreciar esta clase contiene una propiedad llamada DataContext, que es el contendrá una referencia a nuestro DataContext, valga la redundancia, para posteriormente usar los métodos InsertOnSubmit para colocar el registro en “memoria” y luego hacer el Commit a la base de datos con el método SubmitChanges.

image

Para el DataPortal_Update es idéntico sólo que esta vez usaremos la función creada en la clase parcial (GetClienteById para el ejemplo) para que nos devuelva una instancia al registro que queramos modificar, y luego llamamos al método SubmitChanges de nuestro DataContext para persistir los cambios a la base de datos.

image

Y finalmente en el DataPortal_Delete hacemos uso del SingleCriteria para ubicar nuestro registro y posteriormente hacer la eliminación física con la función DeleteOnSubmit que recibirá como parámetro la instancia del registro.

Cabe aclarar que todos los métodos de acción (Delete, Update e Insert) tienen el atributo Transactional definido a TransactionScope el cual manejará la concurrencia y la atomicidad de las acciones por nosotros, pero tengan cuidado pues esto sólo funciona con Bases de datos basadas en Windows, ya que este SO posee el servicio Windows DTC, pero si usan otros RDBMS que se ejecuten en otros SO (Oracle, PostgreSQL, MySQL, DB2, etc.) les recomiendo prescindir de este atributo y usar transacciones manuales que también será tema de investigación en otro post.

En el siguiente post veremos como podremos hacer uso del ContextManager en clases Maestro-Detalle y como podremos sacar provecho de esta potente clase de CSLA.NET y ahorrar mucho código para la gestión de datos.

Espero que les sirva mi “pequeño” aporte.

Saludos desde Lima, Perú.

Anuncios