baja la performance x objetos?

Hola Claudio

Cuando decis:

Se hace mas lenta la ejecucion del sistema al tener objetos.
Porque si mal no entiendo debo tener un metodo para leer cada campo del
archivo clientes y tambien un metodo para grabar en la base y modificar
cada
campo. Entonces paso a hacer muchas llamadas, en vez de por ej. asignarle
los
campos al archivo de clientes y luego grabar en la base.

Creo que hay un error de concepto, supongamos que lees una Factura desde la
base de datos:

Tenes dos caminos.

1- Invocar en una llamada los datos de cabecera, poblar la parte cabecera
del objeto factura y en una segunda los del detalle, poblar la collection de
items de la factura.

2 - Invocar una vista o procedimiento que retorne todo de una sola vez.
Poblar la cabecera y luego los detalles.

Osea, en el peor de los casos tenes dos llamadas para poblar una factura.

Donde puede haber una gran diferencia?
Cuando por ejemplo recuperes una collection de facturas, eso puede implicar
mas llamadas.

Hay frameworks especializados para estas cuestiones que están muy
optimizados, algunos a tal punto que tendrás la misma performance, incluso
superior si utilzan técnicas tales como lazy Load y algunas otras cosas como
caches, etc, etc.

Te recomiendo que le pegues una mirada y pruebes a Cooperator Framework, muy
facil de usar.
Tambien NHibernate, este es muy potente, pero la curva de aprendizaje es
mucho mas dura.

http://www.cooperator.com.ar
http://www.hibernate.org

En cuanto al mantenimiento:

Y si programa con objetos, es realmente ventajoso para el mantenimiento
futuro de los sistemas?
O sea, en la practica realmente se justifica todo el esfuerzo hecho
durante
el diseño?

Es mucho mas simple, la lógica de negocio esta mucho mejor agrupada y si
asignas las responsabilidades correctamente a tus objetos el código pasa a
ser muy documental.
Las reglas de negocio están encapsuladas, totalmente asociadas a las clases
que son expertas en información en una cuestion determinada.
No tenes que recordar que si el campo tal de tal tabla es x y el tal de tal
otra es z entonces eso siginica que .
Encapsulas ese concepto como metodo de una clase que representa un concepto
determinado.

FacturaList fl= FacturaMapper.GetFacturasPendientes(new Cliente(3));

Es muy descriptivo y facil de entender, por ende , facil de mantener.

Por ultimo:

Al programar en objetos, ademas hay que programar en 3 capas?

Si no trabajas en capas, prefiero pensar en layers, no estas separando
correctamente las responsabilidades, por ejemplo.

Factura f=new Factura()
...
...
f.Save();

Es una mala practica, la factura no debería aber persistirse.

Factura f=new Factura()
...
...
FacturaMapper.Save(f);

Es una ejemplo un poco mas clara de buena practica.

Espero que te sirvan los conceptos que explique.

Un saludo

Daniel Calvin


"Claudio" <iaio60arrobahotmail.com> escribió en el mensaje
news:

Hola

Estoy empezando en esto de .net y queria consultarles si alguien programa
con objetos, me refiero supongamos un sistema de facturacion.
Crearon un objeto de clientes, proveedores, facturas de venta, remitos,
etc.?

Se hace mas lenta la ejecucion del sistema al tener objetos.
Porque si mal no entiendo debo tener un metodo para leer cada campo del
archivo clientes y tambien un metodo para grabar en la base y modificar
cada
campo. Entonces paso a hacer muchas llamadas, en vez de por ej. asignarle
los
campos al archivo de clientes y luego grabar en la base.

Y si programa con objetos, es realmente ventajoso para el mantenimiento
futuro de los sistemas?
O sea, en la practica realmente se justifica todo el esfuerzo hecho
durante
el diseño?

Al programar en objetos, ademas hay que programar en 3 capas?

Bueno, muchas gracias y hasta pronto!
Claudio