sábado, 1 de marzo de 2008

LinQ to Sql - Bussiness label


LinQ to Sql (Arquitectura de capas):


Como hemos visto, ya tenemos definida la capa de datos, ahora definiremos la capa de negocios, en este ejemplo, la capa de negocios solo se encargará de capturar las solicitudes de la UI y realizar las solicitudes a la capa de datos, específicamente a la clase dalUsuario, para solicitar o realizar las acciones sobre la entidad lnqUsuarios.


Para construir una Capa de negocios, se deben tener de antemano la mayor cantidad de definiciones de acciones que se deben atender desde la UI (Interfaz de Usuario), por lo cual, ya tenemos claro que haremos en la capa de datos y debemos tener más o menos claro cuales serán las solicitudes desde la UI.

Lo primero que haremos será agregar a la solución un nuevo proyecto de bibliotecas de clase que llamaremos CapaNegocio. Si no saben como hacer esto, deben ir a Archivo, Agregar, Nuevo proyecto y desde la ventana de proyectos seleccionar el lenguaje y el tipo de proyecto que crearemos.
Antes de realizar la siguiente acción, vamos a generar el proyecto de biblioteca de clase CapaDato, para ello con el botón derecho del mouse sobre el proyecto, seleccionaremos la opción generar.
A continuación agregaremos una referencia desde el proyecto CapaNegocio al proyecto CapaDato, si vemos en la carpeta bin del proyecto CapaNegocio, veremos una dll llamada CapaDato.
Podemos construir los métodos de esta capa, si lo desean pueden renombrar la clase que se crea por defecto en el proyecto por brlUsuario (brl por bussiness rules label). Como dije en la introducción de este artículo, los nombres de clase se repiten en los distintos niveles, así como los métodos de las mismas, en algunos casos. Para cualquier caso debemos crear esta clase para continuar con el ejemplo.

En el espacio de nombre de la clase definiremos una variable que referenciará a la clase de la capa de datos dalUsuario, de la siguiente forma:

CapaDato.dalUsuario dalUsuario = new CapaDato.dalUsuario();

Como vamos a trabajar con una solución de UI de windows y vamos a capturar los controles que nos envíen en esta capa, lo que haremos será agregar otra referencia al proyecto CapaNegocio, que referenciará al espacio de nombre System.Windows.Forms, con esto podremos definir variables de tipo de controles de objetos.
Ahora si, piquemos código!!!.

Como sabemos, debemos en nuestra interfaz, desplegar la información de los usuarios, para ello vamos a crear una función que captura la información que se envía desde la UI y realizar las acciones pertinentes, como en este ejemplo no pasaremos los controles a la Capa de negocios voy a poner el código y cada desarrollador, segun su CI jejejeje, interpretará cada función.
Bromas a parte veamos las funciones que crearemos para atender las llamadas desde la UI:

En el siguiente método capturamos toda la información de los usuarios que se encuentran definidos, los cuales serán desplegados de alguna forma en la UI, si observan los métodos de las BRL (Bussiness Rules Label) tienen los mismos nombres que en la DAL (Data Access Label)

public List funUsuarioObtener(){
List usuario = null;
try{ usuario = dalUsuario.funUsuarioObtener(); }
catch (Exception ex) { throw ex; }
return usuario;
}

En el siguiente método capturamos la información de un usuario en especifico según los criterios enviados y retorna la información

public CapaDato.lnqUsuario funUsuarioObtener(string usuario, string clave) {
CapaDato.lnqUsuario cls = null;
try { cls = this.dalUsuario.funUsuarioEspecificoObtener(usuario, clave); }
catch (Exception ex){ throw ex; }
return cls;
}

El siguiente método realiza la llamada a la inserción de un registro al método creado en la capa de datos que realizar esta acción utilizando los m‚todos dispuestos en linq to sql

public void prcUsuarioInsertar(int empleado, string usuario, string clave) {
try { this.dalUsuario.prcUsuarioInsertar(empleado, usuario, clave); }
catch (Exception ex) { throw ex; }
}

El siguiente método realiza la llamada a la modificación de un registro al método creado en la capa de datos que realizar esta acción utilizando los m‚todos dispuestos en linq to sql

public void prcUsuarioModificar(string usuario, string clave, string newusuario, string newclave) {
try { this.dalUsuario.prcUsuarioModificar(usuario, clave, newusuario, newclave); }
catch (Exception ex) { throw ex; }
}

El siguiente método realiza la llamada a la eliminación de un registro al m‚todo creado en la capa de datos que realizar esta acción utilizando los m‚todos dispuestos en linq to sql

public void prcUsuarioEliminar(string usuario, string clave) {
try { this.dalUsuario.prcUsuarioEliminar(usuario, clave); }
catch (Exception ex) { throw ex; }
}

Ahora, cada uno puede hacer las cosas como le parezca mejor, yo solo les entrego los lineamientos Base, ya que claramente si depuro este código desde una perspectiva de reuzabilidad, lo puedo mejorar mucho más.
Bueno señores, el siguiente paso es crear la UI y con esto podemos probar lo que hemos hecho, ahunque debo decir, que tal como esta este ejemplo, lo podemos usar para web, como para windows, ya que como no estamos pasando controles de objetos a la capa no esta personzalidada la Capa, más bien esta habierta y se puede reutilizar en más ambientes.

4 comentarios:

Anónimo dijo...

Hola amigo, es mas que nada una duda, quizas diga una tonteria, pero disculpa, soy principiante en esto. En mi trabajo actualmente, estoy elaborando un proyecto en capas y casualmente me guie por un ejemplo similar al tuyo, de hecho es igual en estructura; sin embargo, me surge una gran duda, que otras cosas puedo poner en la capa de negocios?, pues asi como veo en el ejemplo (y como tengo en mi trabajo), pareciera ser que la puedo omitir y hacer las llamadas directamente desde la capa de presentacion a la capa de datos, pues en la capa de negocios lo unico que esta haciendo es un bypass, solo llama a las funciones de la capa de datos, no hace nada adicional. La cabeza me estuvo dando vueltas unos dias y pense que quizas podria poner validaciones y cacharlas en el try...catch, pero no se si eso sea lo adecuado. Que recomendaciones me darias para la capa de negocios?, formalmente que puedo poner alli?, cabe aclarar que mi proyecto es muy similar, inclusive estoy manejando Linq to SQL. Muchas Gracias!!

gchmex@hotmail.com

Mario Roa dijo...

Estimado amigo.

Claramente en la capa de negocios pareciera que solo sirve para realizar transacciones de pasada (segun este ejemplo), pero en el caso de que quisieras realizar validaciones transaccionales, por ejemplo, si antes de realizar una insercion quisieras verificar de alguna forma una validacion de existencia, es en la capa de negocio donde harias esta accion, ya que llamarias en una misma funcion al metodo de validacion de registro creado en la capa de datos el cual retornaria el resultado a la capa de negocio y dependiendo del resultado realizarias las acciones pertinentes utilizando los metodos de la capa de datos u otros metodos de la capa de negocio.

Esto te permite portabilidad de capas, ya que si esto mismo lo hicieras en la interfaz, y quisieras utilizarlo en otra aplicacion, tendriamos que copiar el codigo.

Otra ventaja es la posibilidad de crear y cargar controles de interfaz, pasando estos a la capa de negocio y en esta cargar la informacion que debe tener un control, por ejemplo un listbox o un combobox, si mas adelante, por el tema de portabilidad deseas reutilzar la carga de datos como se haria en OO, en otra aplicacion que utilice los mismos controles, solo debes reutilizar las capas pertinentes. Algunos dirian que esto no es lo correcto, pero crearian otro proyecto para hacer lo mismo, que en referidas cuentas pasaria a la capa del negocio, por que serian politicas del mismo.

La capa de negocios es muy importante, sobre todo si se desea ademas definir las reglas generales del negocio, como validadores de cuenta, validarores de personas, que generalmente tienen formulas de empresa y no deben ir en la capa de interfaz, por seguridad.

Espero que esta pequeña respuesta te haya ayudado.

No suelo responder estos correos pero la pregunta sobretodo, a una persona que esta empezando, merecia una respuesta.

Anónimo dijo...

Hola a todos,
referente a lo que se indica en el primer comentario, muchas veces en la capa de negocio solamente se pasan las funciones de pasada, a veces creo que no vale la pena crear la capa de negocio ya que las validaciones hechas en el mismo, las puedo hacer desde la capa de presentación.
Por ejemplo, creo que LINQ to SQL no es adequado trabajarlo en tres capas sino en dos capas. El archivo que se crea para mapear las clases con LINQ sería mi capa de datos ya que el se encarga de hacer el acceso a datos sin tener que escribir ninguna línea de código en SQL.
Este es mi punto de vista, no sé que pensarán los demás.
Adiós.
Escrito por: Anónimo.

Mario Roa dijo...

Dentro de una arquitectura de proyecto existe la posibilidad de trabajar en multiples capas, dependiendo del negocio se pueden desarrollar de una a n capas.

Dos definiciones de proyectos implican que se trabajan con tres capas, ya que la Base de datos tambien cuenta como capa y la capa de datos en la que se define el mapeo a la Base de Datos es la de acceso a datos, si el proyecto es simple, puede contener las reglas del negocio, pero cuando un proyecto es de gran lógica y requiere una capa de negocios esta debe ser definida a parte.

Para poder entender el concepto de capas, se debe tener una buena base practica, así como manejar muy bien la teoría, todo esto acompañado de experiencia en proyectos grandes, ya que si solo se trabaja en proyectos pequeños se observará generalmente lo que a descrito el usuario anterior