Daniel, me hiciste venir a la mente el tema de addins y creo que voy a
forzar esta implementacion en lo proximo que haga  :)

 

Volviendo al tema voto por la opcion 2, agregar informacion en el archivo de
configuración termina siendo incomodo siempre, y cuando el sistema va
creciendo tenes que manejarte con muchas configuraciones…

Aunque como desventaja puede ser que sea un poco mas lento que la opcion 2,
creo que vale la pena…

 

Yo haria atributos a nivel assembly (especificandole la/s clase/s que son
drivers) o a nivel clase para definir los drivers. Cada clase Driver tendria
información general (nombre, autor, version, modelo de escaner, etc…) y la
capacidad de devolver instancias de 2 objetos principalmente:

 

1)       El objeto que realmente implementa el protocolo y tiene un metodo
como Escanear() : Image

2)       El objeto UI, que simplemente podria ser un control que implemente
una interfaz con algunos metodos basicos (MostrarDefaultInfo,
GuardarCambios, etc…)

 

 

Saludos!,

Diego

 

  _____  

From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Daniel
Calvin
Sent: Jueves, 01 de Marzo de 2007 22:53
To: [email protected]
Subject: [puntonet] Debate sobre como diagramar esta aplicacion

 

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 

Responder a