Hola Diego

Sip, lo de las configuraciones es cierto, pero es facil con net 2.0 hacer
clases para configuración y una aplicacion que las maneje.

En cuanto a la opción assemblies donde decis:
Yo haria atributos a nivel assembly (especificandole la/s clase/s que son
drivers) o a nivel clase para definir los drivers.

Ahi prefiero averiguar si realmente la clase hereda de la clase
SCNDriverBase, por ejemplo o si implementa la interface ISCNDriver. ( o
algun nombre mas feliz, son las 12:56 no da pa crear mucho... :)  )
Esto solo para asegurarme de instanciar sin encontrarme con un martes 13....

Tal vez si adornaria la clase con atributos para obtener info adicional del
driver, nombre, autor, version, modelo de escaner, etc…) , tal como vos
propones.

He usado los metodos que mencione en el email anterior, ambos sirven y no
presentan mayores diferencias. Cuestion de gustos...

Abrazo señor

Daniel


El día 1/03/07, Diego Jancic <[EMAIL PROTECTED]> escribió:

 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




--
Daniel A. Calvin
Cooperator Team Member
http://www.cooperator.com.ar
Microsoft Certified Professional

Responder a