Patrón Factory y otro enfoque de las 3 capas

Y aquí tenéis un artículo donde explica en español (no sé si bien o mal, espero feedback) el patrón Factory y ejemplificado sobre C#. Ha surgido este patrón en el diseño de controles personalizados para las clases de negocio, ya que no podemos incluir en las clases un ToControl() que nos devuelva este control ya referenciado a ese objeto, puesto que así el negocio dependería del interfaz. Podría hacerse pasando una fábrica de controles al negocio (con un método que para un objeto, cree un control del tipo adecuado y lo referencie a ese objeto). Todo esto relacionado con la posibilidad de definir listas heterogéneas usando FlowLayout, iremos profundizando en esto.

Otro enfoque a la arquitectura en 3 capas, aunque poco rigurosa, y basada en procedimientos almacenados, en este curso de Universidad .NET (hacen falta altavoces). No lo recomiendo a no ser que estéis muy aburridos, el profe es un poco cansino (como en todos los webcast, supongo), y ya digo que no es muy riguroso con la separación en capas, parece que su principal preocupación está en el rendimiento (curioso ver cómo carga de una sola tacada un dataset con el registro a modificar y 2 tablas más con los datos para rellenar los combos con los que modificar 2 campos particulares de esa tabla) por lo que no se ruboriza en pasar los dataset hacia fuera.

Aunque no termina de solucionarlo, uno de los problemas que plantea lo tenemos aún pendiente en nuestro diseño: ¿cómo compartir la conexión a la base de datos entre los objetos de la forma más transparente posible? Un primer enfoque consiste en (tal como hace el profe) usar una propiedad de la clase base de la jerarquía de objetos de negocio (a la que nosotros llamaremos EBase). Asignando esta propiedad una vez, los objetos que necesiten acceder a la base de datos podrán accederla directamente ya que todos heredan de esa clase. Quizá nos conformemos con este enfoque, a pesar de tener muchas lagunas, para nuestro Proyecto Sota actual, que sólo trabajará con una sola base de datos.

Arquitectura en 3 capas según Microsoft

Navegando con mi barquito me he encontrado con este artículo donde Microsoft explica (en diciembre de 2002) cómo diseñar una aplicación en 3 capas sobre la arquitectura .NET. El artículo en sí es bastante extenso, en el capítulo 2 es donde se mete en materia en las 3 capas, el resto es también interesante pero son aspectos secundarios. Está bien para asentar la idea de las 3 capas, madurar nuestro concepto y aprender de algunas ideas que aportan (como la separación de las clases de negocio en Entidades y Componentes).
Todo esto de las 3 capas está mucho más simplemente explicado por un tal Francés que no parece español pero que sí escribe en cristiano (aunque un poco malo) en el artículo Desarrollo de una aplicación en 3 capas con VS.NET, también interesante.
Y para terminar, llegamos al artículo desde el que he comenzado a navegar, el más avanzado por las ideas que aporta, muy cercanas a nuestros generadores de código nibiCod que usan xml y xslt, pero partiendo de las tablas de una base de datos y generando los objetos de negocio mediante una librería llamada CodeDOM.
Nunca había mirado yo la revista esa MJT.net, creía que se dirigía a Java, supongo que será por la J. Lo bueno: que está en castellano (anda, que no os queraréis, que hoy no pongo nada en inglés).

Ideas para la interfaz de usuario

Hoy, como está todo el mundo enfermo, Caña y yo nos hemos entretenido en investigar mejoras para la interfaz de usuario. A ver si se recuperan los enfermuchos (saludos a Jorge y a Berny). Ahí van esas ideas...

Primera idea: incluir Flash dentro de una aplicación Winforms de C#
En el artículo http://www.elguille.info/colabora/puntoNET/felixcriv_Flash_y_Net.htm nos dan la idea para incluir un control que pueda contener una pelicula Flash (swf), explicándonos muy sencillamente los mecanismos de comunicación hacia fuera (disparar eventos al ser pulsados los botones y cosas por el estilo) y hacia dentro (estableciendo una variable). Lo hemos probado, y aunque nos ha costado incluir un visor de Flash en un Form (porque no aparecía el control en la paleta, había que mostrarlo con el botón derecho y Choose items...), finalmente ha sido muy fácil mostrar una película (que por cierto se ve en tiempo de diseño, muy chulo), responder a sus eventos y cambiar sus variables internas y que responda a ello. Este de las variables es un método muy arcaico porque exige que dentro estemos 'iterando' constantemente para detectarlo, así que posiblemente lo hagamos con una clase que enmascare estas dificultades, y que en vez de cambiar variables lo que haga sea mover la película a un fotograma concreto, u otros mecanismos que aún no hemos descubierto pero que seguro que existen.

Segunda idea: hacer asistentes (wizard) en .net
Buscando otra cosa he encontrado el artículo http://www.differentpla.net/node/view/403, que detalla como implementar un formulario genérico para elaborar asistentes, pasándole los formularios que constituyen las pantallas de ese asistente. Una idea sencilla y buena, y parece que muy bien implementado en el artículo. No hemos probado nada de esto, pero lo haremos pronto.

Y última idea: usar un modelo de ventanas tipo explorador, con botones adelante y atrás.
En lugar de usar un entorno MDI donde pueda haber abiertas varias ventanas a un tiempo, sólo vamos a permitir una ventana, por lo que una nueva ventana aparece en el mismo espacio donde estaba la anterior y la oculta (igual que las páginas web). Pero para compensar al usuario, vamos a intentar implementar un sistema de recordar las últimas ventanas y volver a ellas usando botones como Atrás y Adelante, igual que si la aplicación fuera un navegador, aunque sea realmente una aplicación WinForms. De esto no he encontrado ningún artículo que plantee ideas similares, pero seguiremos buscando y si no lo construiremos nosotros desde cero.

Bueno, recuerdos a los enfermitos, que se recuperen pronto, y me voy ya que ya es hora.

Proyecto en marcha

El proyecto ya ha comenzado, y hago un pequeño resumen de la primera semana:

• La primera tarea, toma de contacto con .NET y elaboración de los primeros objetos de negocio (EEmpleado, EUsuario y EMecanico), se desarrollo con mucha sencillez y rapidez. Habrá que profundizar después en estas clases, ya que de momento sólo ofrecen sus propiedades y punto.
• A continuación creamos un formulario FEmpleado que conectamos usando ObjectDataSource a nuestra clase EEmpleado. Fue muy sencillo, la verdad es que en .NET 2005 han hecho un gran trabajo con esta fuente de datos, al menos en primera instancia (ya le daremos leña más adelante), tardamos 5 minutos en conectar los controles y en ver como se actualizaba el objeto y cómo se actualizaba el control al cambiar el objeto. Una gozada.
• Lo siguiente sabíamos que iba a ser más costoso: la persistencia. Para esto, comenzamos por definir las etiquetas Tabla y Campo para nuestros objetos de negocio, como Attributes de C#. Su utilización fue sencilla, y tras añadir los atributos CampoClave (para la clave primaria) y CampoReferencia (para las claves foráneas), ya esta semana estamos trabajando en aprovechar al máximo esta información de que disponemos, ya no sólo para efectuar la persistencia, sino incluso para crear la estructura de la base de datos a partir de las clases de negocio, o para actualizar una base de datos existente cuando cambie el programa (o sea, la capa de negocio). Todo esto está muy bien, pero para un proyecto de iniciación como es este no queremos pararnos demasiado en estas etapas, así que una vez concluida la generación de tablas vamos a pasar de la actualización y nos meteremos a saco con la persistencia de las clases, la clase CPersistor que nos permita leer y guardar objetos de negocio de la base de datos con un mínimo esfuerzo.

En este paso de la etiquetación de las clases han surgido ideas y dudas, es una zona bonita por explorar, en estrecha relación con la BD. Por ejemplo, hemos decidido no usar tipos de datos de la base de datos, sino establecer una correspondencia entre los de la Property del objeto de negocio y los de la BD concreta en que estemos realizando la persistencia.
Por otro lado, también han surgido ideas para ampliar la utilización de estos atributos a su uso en el rellenado de combos (nos dan la columna clave, y el contenido lo obtenemos con ToString; aunque quizá no sea lo más conveniente, sino heredar Id de ENegocio y así contar siempre con ese valor igual que contamos siempre con ToString) o la generación automática de consultas (listados) a partir de objetos de negocio, seleccionando qué columnas queremos ver (qué campos), incluso con la posibilidad de navegar entre objetos según sus relaciones (con la información de la etiqueta CampoReferencia podemos construir los JOIN en la consulta).