JuanCri
unread,Nov 16, 2008, 4:39:07 PM11/16/08Sign in to reply to author
Sign in to forward
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to Factura Sharp Desarrollo
En la lista de Mono Hispano, discutimos ya algo sobre la arquitectura
de Factura Sharp. Para muchos, es una preocupación el tener
aplicaciones multi plataforma.
Algunos argumentaban, y me uno a esa idea, que en realidad debemos
enfocarnos en bibliotecas y servicios. De hecho, creo que deberíamos
enfocarnos en el nivel más bajo posible y crear bibliotecas. Estas
bibliotecas deben ser capaces de realizar las tareas más comunes de la
facturación electrónica, siendo totalmente agnósticas a la
implementación de arquitectura y visual que tendrá la solución final.
Por ejemplo:
FacturaSharp.Ejemplo.Signing puede ser una biblioteca de firmado de
documentos tributarios electrónicos. Esta biblioteca simplemente
expone las rutinas necesarias para el firmado.
Una vez que está implementada, se puede llamar desde una aplicación
(sea cual sea su tipo o toolkit gráfico). Esta aplicación podría, por
ejemplo, ser utilizada en una computadora, teniendo todos los recursos
en forma local, de una PYME.
Una opción distinta a esta aplicación es el uso de un servicio
intermedio, el cual puede tener colas, repositorios de firmas y un sin
fin de otros componentes empresariales, lo cual permitiría tener una
solución mucho más robusta para las situaciones donde se requiera.
Una tercera posibilidad es un desarrollador que sólo quiere firmar
documentos en un servicio web. Implementa este servicio llamando
directamente a la biblioteca y recibiendo todos los parámetros desde
el cliente.
Una cuarta posibilidad es una pequea aplicación de consola que firma
documentos.
El crear estas bibliotecas, finalmente, puede ser la opción más
general, que nos permita ir luego enfocándonos en las capas
superiores, permitiendo que el código y el esfuerzo sea lo más
reutilizable posible. Mi propuesta es que nos enfoquemos sólo en esta
capa, en una primera instancia. Una vez que estas bibliotecas sean lo
suficientemente robustas, podemos esperar a que las necesidades
específicas de distintos grupos y desarrolladores sean las que definan
las aplicaciones que serán utilizadas por usuarios finales.
Por supuesto, los comentarios e ideas son siembre bienvenidos.
Atte,
Juan Cristóbal Ollivares