[orfeo]

Empezado por JorgeBec

viendolo analiticamente yo crearia una instancia de factura por que se que ese objeto tiene un metodo dar de alta, pero no, partiendo nuestro codigo en las capas que me menciona el colega marto, primero seria llamar a la interfaz frmAltaFactura(por ejemplo) la cual a su vez invoca al objeto factura, desde mi punto de vista se pierde la interpretacion de UML. No creen???, es decir seria mas facil encapsular la Interfaz de usuario en la clase factura, o bien planear tu codigo a manera que tu interfaz tenga una total correspondencia con un metodo de una clase que necesite de una interfaz no creen???

Y que arias cuando deceas Cambiar un componete grafico, tendrias que cambair todo el objeto factura y la idea es poder cambiar una capa sin tener que cambair mucho la otra.


Talves no me esplique bien en el otro mensaje, frmAltaAfactura no llama a unaFactura (obj), se la madas como parameto (o una coleccion de ellas). para formar la capa View que te contaba de MVC., osea la capa view seria el from.

Dependiendo de la interaccion del formulario (cambios) el objeto se actualizaria, supogamos que definis un evento onChange de un label llamado lblPrecio.
Cuando el label cambia se produce un evento e invoca un metodo unaFacura.setPrecio(value);
Esta interracion entre los componentes visuales y el obj unaFactura seria mas o menos la capa Control.
Para lograr una separacion 'perfacta" deberias definir eventos en el objeto unaFactura para que informe a los componentes graficos que se actualicen solos al cambio de unaFactura.
Estos eventos informarian de un cambio en un valor, y el conponete que le interese dicho cambio pediria el nuevo valor.

con esto estas separando la capa de UI de la informacion, podrias cambiar la estructura/implementacion del Objeto sin cambair la UI, o cambiar la UI (tipos de componentes) sin tener que tocar el objeto factura. Dado que este ultimo no conoce los componetes visuales. Adentro de el nunca tendrias un lblPrecio.text:=value;

y ahora solo te falta separar la DB, que en realidad ya lo esta. al tener un objeto.., el objeto es la DB, el es el responsable de mantenerce consistente con la DB al momento que el cambia.
Pero en realidad a mi gusta mas la idea de tener un obteto que le mandes la factura, ej. DB.commit(uanFactura);


De culquier forma no se puede logra una separacion absoluta entre la entre los datos y la UI, termina jugando la complejidad para programarla y la performance. (pensa cuando usamos un DBGRID para listar y hacemos que el user defina los tipos de busqueda, es muy dificer tener una buena performance sin usar un DBgrid, si las tablas son muy grandes)


Para que te convensas podrias buscar algun libro que explique diferentes arquitecturas de UI, las vas a poder relacionar y te vas a dar cuenta que ninguna es milagrosa. Yo te decia la MVC porque la estoy empresando a aplicar (muy rudimentariamente) y es vastante buena viendola con respecto al costo de programarla.

Por tus dudas de UML, es un lenguage de Modelado, que te sirve para modelar cualquir cosas, desde requeriminto, diseno, arquitecturas, cualquier cosa O.O.
No se que tan abansado tenes tu proyecto, pero si ya definiste el Diagrama de clases, tendrias que descrivir con algun diagrama de iteracion los casos de uso y te vas a empezar a dar cuenta las relaciones entre las clases.

Luego de eso deberias empesar a definir las interfaces de las clases y como interactuan (quien llama a quien y como lo hace) , luego de esto vas a empesar a ver el codigo dibujado (dependindo de la experiancia de uno, es lo que dicen), es mucho mejor darte cuenta que tenes un error o que te falta algo que no tubiste en cuenta, talves algun caso mas... en un dibujo que en el codigo ya programado.
Y esto realmente te lo da la experincia, porque te lo tenes imaginar, de la misma forma que cuando uno codifica la idea que uno tiene en la cabesa de un programa, la ventaja que al dibujarlo podes encontar errores antes de codificar.

Bueno, cualquier cosa segimos debatindo, me biene justo porque el 11 rindo desarrolo de sofware.
Ha por casualidad nadie esta interesado en debatir antes del 11 el tema FrameWorks?