En el caso de la capa de aplicación, Asp.Net 2.0 no requiere que se ubique necesariamente código de la lógica de la aplicac. en el archivo code-behind, ya que también se puede agregar el mismo en el código de presentación (.aspx). De todas formas siempre es aconsejable mantener separado las lógicas de aplicación y presentación.
En el caso de la capa de acceso a datos, no es aconsejable acceder desde la capa de aplicación directamente a la BD ( ya sea a través del llamado a procedimientos almacenados ó vía ejecución de comandos SQL) , siempre es mejor crear clases que accedan a la tecnología usada en el acceso a datos; porque ?
Porque con esta decisión de diseño, tendremos las siguientes ventajas:
- El código de acceso a datos se aísla en una clase separada, por lo cual podemos poner a trabajar a nuestros expertos en BD, mientras los analistas y programadores de lógica de aplicación trabajan en la otra capa.
- Podemos afinar la perfomance de la BD (tiempos de acceso, pruebas de stress, etc) sin afectar el resto de la aplicación con nuestros cambios.
- Podemos migrar de tecnología de acceso a datos, por ej.: de SqlServer a Oracle, ó a un ORM (Nhibernate ó Linq, etc); sin afectar las otras capas. (capas como módulos pluggables)
OK, me convencí, voy a generar mis clases de acceso a datos con las operaciones básicas de persistencia (CRUD: Create-Retrieve-Update-Delete), aunque tener esta flexibilidad, no posee ningún costo asociado?
SI lo posee, debido a que Asp.Net está diseñado para trabajar con los controles de las fuentes de datos embebidos en nuestras páginas .aspx, soluciones?:
- No usar las fuentes de datos (DataSources) de Asp.Net, lo cual significa que no podremos usar “data-binding” en nuestras presentaciones, por lo cual debemos escribir el código que conecta la interfaz de usuario (IU) a las clases de acceso a datos.
- Usar la nueva fuente de datos de objetos (ObjectDataSource) de Asp.Net 2.0, la cual está diseñada para ligar los controles Asp.Net a clases de acceso a datos, aunque esto agrega una capa de complejidad que en algunos casos tampoco soluciona el problema.
Los Web User controls (.ascx) se incluyen en los Web Forms y permiten la reutilización de código en la capa de presentación.
Los Master Pages (.master) son templates que pueden ser aplicados a gran número de Web Forms , para asegurar consistencia visual y funcionalidad a través de varias páginas del sitio. Normalmente usados para encabezado y pie de nuestro sitio, mapa del sitio, columnas con menúes.
Controles del lado del servidor, existen 2 categorías:
- Html, permiten acceder a los elementos HTML de la página a través del código (en el code-behind). Se transforma un control Html (Button, TextBox, RadioButton,...) a un Html server agregandole el atributo “runat=server”. La mayoría de los controles Html están duplicados con mayor funcionalidad en los controles Web server, aunque a veces ud. deberá usarlos.
- Web server, son clases .NET compiladas que, al ser ejecutadas, generan código Html como salida, eventualmente pueden incluír scripts del lado del cliente.
Pueden ser usados en los Web Forms en forma directa ó a través de la creación de Web User controls. Estos incluyen controles simples como TextBox ó Button, y otros más complejos como el GridView (el viejo DataGrid) que permite mostrar datos de la BD en forma de tabla con manejo de muchas propiedades de diseño y eventos.
Aquí se puede editar el código html y los controles Web de asp net que han sido agregados en modo de diseño (encapsulados en los tags
Por último un ejemplo del code behind (.aspx.cs) de esta página, donde normalmente generamos nuestro código de manejo de eventos de la página y de los controles :
Con este post he intentado demostrar a aquellos que no han programado con AspNet, las principales características de la arquitectura clásica de desarrollo web, así el lector podrá comprender mejor las diferencias existentes contra la nueva propuesta del MVC para AspNet posteada anteriormente.
6 comentarios:
Hola!!
Me gustaria escuchar que opinan sobre utilizar la arquitectura doodads .net ,que se suele emplear con la herramiena de generation de codigo Mygeneration.
Utilice esta arquitectura para hacer un proyecto Win Forms. Utilizo Mygeneration para crear una capa DAL y BLL.
Alguien hace uso de esto para aplicaciones Web o algo parecido sin caer en una pattern MVC.
Es recomendable usar lo que yo comento.
Emanuel, gracias por comentar.
No sabia de doodads.net, pero al buscar veo que su tecnologia fue usada para desarrollar EntitySpaces .NET , el soft que IBA a ser el framework ORM que Microsoft pondría en su nuevo Net 3.0 (despues de tantos agregados es ya 3.5...). El tema es que lo descartaron para poner su proyecto más cercano a sus DataSets tipados que fue finalmente LINQ , especialmente LINQ for Sql.
Como siempre en este ambiente del desarrollo de software, antes de hablar hay que probar las herramientas; asi que me bajé su quick reference (http://www.mygenerationsoftware.com/dOOdads/doodadsQuickRefCSharp.pdf) para instalar y probar, luego podría agregar algo a través de un post. En mi experiencia con frameworks ORM, he probado con ORM (de olero) que ya no tiene soporte y se basaba en mapear clases desde la Base de datos (tecnologia inversa), cosa que a mi parecer no es correcta ya que todo debe comenzar desde el armado de un modelo de objetos con su corresp. diagrama de clases y luego la herramienta ORM deberá generar las tablas relacionales para persistir las clases que lo requieran. Tambien ActiveRecord de Castle (los fundadores de MonoRail) y obviamente NHibernate, que a mi entender es el más potente y std. de todos aunque a veces cuesta integrarlo con nuestros proyectos en .NET (el databinding con los controles visuales es todo un tema..).
Emanuel cuando hablas de que creas una capa DAL (data access layer) y una BLL (business logic layer) estás creando en 3 capas lógicas!!, aunque no creo que puedas generar un MVC (donde RubyOnRails es su exponente máximo y MS va por ese camino, ver metodologiasdesistemas.blogspot.com/2007/11/el-futuro-mvc-de-asp-net.html ), ya que deberías crear clases que fueran tu capa "Controladora de Recursos", la cual debería crear las Vistas adecuadas, esto es muy dificil de aplicar en sistemas de tipo WinForms. Lo importante es no confundir "3 logic layers" con MVC.
Espero que me cuentes que uso le das a través de un ejemplo y que componentes (dlls) generas en tu proyecto para fomentar la reutilización de las capas, gracias nuevamente por comentar.
Jorge.
Hola Jorge, como estás, muy interesante el blog, te comento que estoy desarrollnado un e-commerce de venta de libros, más conocido como "carrito de compras", el sistema tiene que contemplar seguridad, errores, idioma, bitácora y persistencia. Hasta ahora definí las capas lógicas UI->BLL->DAL, la pregunta es, ¿donde y de qué forma agrego los servicios descritos?. ¡Muchas gracias!.
Hernan, validación de errores en cada capa. Para la IU validarás a nivel de entrada de datos, en la BLL chequearás las reglas de negocio en tus clases del dominio (Cliente, Carrito, Producto,..), en la DAL los errores en las operaciones CRUD sobre la BD.
La persistencia de los objetos se encuentra en la capa de DAL, yo armo DAOs para mis objetos de negocio (ver ejemplos de 3 capas en mi blog).
La seguridad de acceso, logins y auditorias, es un subsistema aparte que debería interactuar con tu sistema de carrito de compras. Este susistema tambien podrias diseñarlo en capas.
Saludos.
Tengo una duda que me da vuelta en la cabeza.
Tal como se menciona en éste documento están los archivos .aspx y su codebehind .aspx.vb o aspx.cs en donde, como bien dices, generamos nuestro código de manejo de eventos de la página y de los controles.
Según entonces lo mencionado. ¿se podría asociar ésto a programación en 2 capas (omitiendo claramente la capa de modelo)?
¿...
capa presentación -> .aspx
capa controlador -> .aspx.vb
capa modelo -> .vb
...?
Publicar un comentario