----- Original Message -----

From: Pablo Zagni

To: DesarrolloDelphi@...

Sent: Wednesday, September 24, 2008 1:41 PM

Subject: Re: [Delphi] OOP

Ok.. pasame lo que puedas.. igualmente.. no se si implementar ECO y/o .NET, delphi 7 con firebird es MUY estable y fuerte... todavia no tengo la necesidad de subir de nivel.

Esto se va a ver en el curso que dan ustedes?

Saludos
Z

Pablo Soligo escribió:

Hola Pablo,

 

Como te decia, si se les ocurrio, por lo menos con ECO/ASP.NET puedo enlazar lista de objetos a los ECODataSource y estos a las grillas, editores (TEdits) etc para manejarlo DBAware. La verdad no se con instant objects (http://www.instantobjects.org/) y sino se puede hacer a mano. Por alli se sugiere el Modelo-vista-contralador que atiende lo que vos pedis, tengo documentacion oficial  de codegear sobre esto que te puedo pasar si te interesa, con el ejemplo de codigo tambien.

 

Saludos.

Pablo

 

----- Original Message -----

From: Pablo Zagni

To: DesarrolloDelphi@gruposyahoo.com.ar

Sent: Wednesday, September 24, 2008 12:50 PM

Subject: Re: [Delphi] OOP

Pablo!!

Te entiendo...
Suponete.. estoy desarrollando una aplicación de facturación. Tengo 2 sistemas, 1 de administracion donde cargamos los productos (donde estan los ABM, 100% data aware) y otra de facturación, donde se arma el comprobante, y sería + OOP, ya que por ej, no se puede facturar si no hay stock.
Ahora bien... tengo que programar las mismas validaciones para el DBAware y para el objeto en la otra aplicacion! un garron...

Ahora... soñando... si pusiera "tirar" un componente "TArticulo" en mi form, estaría barbaro linkearle los componentes DBAware a mi TArticulo!!! Por ej... un TDBNumericEdit que edite una property numérica del objeto....

Nunca se les ocurrió hacer algo así?

Creo que HOY, tendría que diseñar un "componente" y registrarlo en el Delphi para que funcione... no?

Z

Pablo Soligo escribió:

Utilizar un mapeador, pero cuidado, desde mi punto de vista lamentablemente existe una incopatibilidad entre los lenguajes que son orientados a objetos y las bases de datos que son relacionales. Tratando de salvar este problema (Particularmente el modelo relacional me parece muy limitado respecto al modelo de objetos) aparecen los mapeadores objeto-relacional : Hibernate/NHibernate, ECO, Instant objects, Bold etc, etc. Yo solo he utilizado ECO en aplicaciones ASP.NET, no puedo hablar de los otros. Estos mapeadores se toman el trabajo de cargar en objetos las informacion de las bases de datos. El problema puede ser entonces como estos mapeadores se llevan con los componentes Data-Aware, datasource etc. El caso ECO-ASP.NET salva bastante bien este problema, para win32 esta Instant objects, bold y se que hay otros mas, pero no se que tal funcionan.

Para mi si tenes que desarrollar una aplicacion de gestion administrativa, muy de base de datos, me parece mejor ir al clasico dataset-datasource-dataaware etc y dejar la OOP para los componentes, las ventanas etc.

Si tenes que salirte de la aplicacion administrativa tradicional por ejemplo, desarrollar aplicaciones GIS/Control de acceso/Juegos/Telefonia/Video/ etc el modelos de objetos puro puede ser una alternativa.

 

Saludos.

Pablo

__________ Información de NOD32, revisión 3467 (20080924) __________

Este mensaje ha sido analizado con NOD32 antivirus system
http://www.nod32.com