Hola Gente Coincido con Diego.
Te recomiendo implementar Dependence Injection, vas a necesitar tu Factory para implementarlo, pero todo trabaja en forma dinámica. Tus Drivers, Proveedores o como quieras llamarlos deberían o implementar una interface o heredar de una clase, abstracta seguramente sería una buena opción. De esta forma agregas Proveedores en forma dinámica, para ello tenés varias opciones: 1 - Agregar la DLL de un nuevo Proveedor en una carpeta determinada. Agregar en el archivo config de la aplicación los drivers disponibles para trabajar. 2 - Agregar la DLL de un nuevo Proveedor en una carpeta determinada. Tener un artefacto especializado, un helper, que invoques de tu aplicación y verifique usando reflection esas DLLs para determinar cuales son Proveedores, por ejemplo verificando que hereden de la clase abstracta mencionada anteriormente o implementen la interface determinada. La opción 1 es muy comoda, incluso se puede agregar en el config una descripción del Proveedor, por ejemplo para saber que scanner soporta, no requiere un gran esfuerzo de programación. ( Sobre todo en net 2, donde es muy simple escribir calses específicas de configuración. ) La opción 2 es mas compleja de implementar, al menos si no tenés experiencia utilizando reflectión, por otra parte deberías incluir en esta opción una propiedad que describa a que scanner pertenece el Proveedor. ( lo implementaria sobre escribiendo el ToString() ) Si queres te mando un ejemplo funcional, es de un framework para hacer log de eventos enn tiempo de ejecución, que utiliza algo parecido a la opcion 1. Tiene una clase para manejar la configuración en forma transparente, un helper para crear objetos en tiempo de ejecución en base a información del config, y no mucho mas. Saludos Daniel Calvin El día 1/03/07, Diego Jancic <[EMAIL PROTECTED]> escribió:
Hola Federico, Con respecto a las diferencias de funcionalidad creo que tenes 2 opciones dependiendo de la extensibilidad que le quieras dar a tu aplicación: 1 ) Que el driver del escaner tenga información plana sobre las funcionalidades que soporta, con el objetivo de que la UI le pregunte al driver si soporta o no X feature.. 2 ) Que el driver tenga la UI que requiere para su propia configuración, de esta forma es mas complejo crear un driver pero podes agregar cualquier cosa. De esta forma es como funcionan las impresoras en Windows y existe la posibilidad de imprimir a PDF utilizando propiedades que una impresora normal no tiene (ej: Nombre del Archivo, Contraseña, compatibilidad de versiones del Acrobat Reader, etc..) Saludos!, Diego ------------------------------ *From:* [email protected] [mailto:[EMAIL PROTECTED] *On Behalf Of *Federico Lazarte *Sent:* Jueves, 01 de Marzo de 2007 16:45 *To:* [email protected] *Subject:* [puntonet] Debate sobre como diagramar esta aplicacion Estimados. Tengo una componente utilizada para la adquisicion de imagenes a travez de escaneres. Esa componente fue realizada en su principio para un modelo de escaner especifico. Ahora se la quiere adaptar para poder usar con mas de un tipo de escaner, el problema es que hay codigo especifico del escaner original que hay que separar del codigo de la aplicacion en si y de la capa de presentacion. Estube pensando en aplicar el patron factory asi de acuerdo al dispositivo instalado, instanciar las clases necesarias para ese dispositivo. Alguien tendria otra forma de diagramar este proyecto?. Hay que tener en cuenta que cada escaner tiene sus propiedades y algunos tienen funcionalidades que otros no, pero la aplicacion las contempla. Muchas gracias. Federico ------------------------------ Prueba algunos de los nuevos servicios en línea que te ofrece Windows Live Ideas: tan nuevos que ni siquiera se han publicado oficialmente todavía. Pruébalo <http://ideas.live.com/>
-- Daniel A. Calvin Cooperator Team Member http://www.cooperator.com.ar Microsoft Certified Professional
