Trabajo con clases de Negocio

Si te has decidido por usar clases para las entidades de negocio me parece
que usar data tables también, es inconsistente y produce falta de
homogeneidad.

Por otra parte ¿No sería mejor generalizar los métodos de
carga o búsqueda y llamarlos todos igual? Por ejemplo que todas las clases
de servicio de acceso a datos para una determinada entidad tuvieran un
método llamado Search con un parámetro llamado criteria y que ese método
devuelva una colección de entidades en vez de un datatable

> No claro, pero la clase puede tener distintos metodos, e ir llenando los
> campos de acuerdo a la necesidad, en el ejemplo de cliente y domicilios
> FillBasico () //cargo solo los datos basicos de un cliente, digamos ID,
> nombre o razon social
> FillCompleto () //carga todos los datos del tiemp
> FillDomicilios () //carga solo los domicilios de ese cliente

Lo mismo para esto: un único método Fill con un parámetro que inique qué
se
quiere cargar.

Pero tener un constructor al que se le pasa el Id parece antinatural.
Parece
más natural tener un método en la clase de servicio llamado por ejemplo
GetByKey al que se le pase como parámetro una de sus claves (la clave
primaria o cualquiera de sus claves candidatas)

La discusión inicial es acerca de cual es la manera más adecuada de
implementar un modelo de "clases de negocio" en el que se mapean clases con
tablas y/o vistas y propiedades con columnas.

No si para crear aplicaciones
que acceden a bases de datos el mejor enfoque es usar tal modelo u otro
modelo más genérico como el que defiendes y en cuya discusión no pienso
entrar.

Si te has decidido por usar clases para las entidades de negocio me parece
que usar data tables también, es inconsistente y produce falta de
homogeneidad. Por otra parte ¿No sería mejor generalizar los métodos de
carga o búsqueda y llamarlos todos igual? Por ejemplo que todas las clases
de servicio de acceso a datos para una determinada entidad tuvieran un
método llamado Search con un parámetro llamado criteria y que ese método
devuelva una colección de entidades en vez de un datatable

Si te has decidido por usar clases para las entidades de negocio me
parece
que usar data tables también, es inconsistente y produce falta de
homogeneidad. Por otra parte ¿No sería mejor generalizar los métodos de
carga o búsqueda y llamarlos todos igual? Por ejemplo que todas las
clases
de servicio de acceso a datos para una determinada entidad tuvieran un
método llamado Search con un parámetro llamado criteria y que ese método
devuelva una colección de entidades en vez de un datatable

Lo que sucede es que seguramente, debido a mi inexperiencia, no alcanzo a
dimensionar esa inconsistencia y falta de homogeneidad, los dataTable son
lo más parecido al Recordset de VB6 ADO donde yo levantaba los datos de la
BD y trabajaba con cada uno de los campos con mucha flexibilidad.
En nuestro modelo (y me imagino que en el de muchos que se dedican a
aplicaciones de gestion) las consultas o los datos son necesarios
extraerlos de muchas tablas y me encontre con la dificultad de encontrar
una coleccion de entidades que pueda representarme lo que estoy buscando.

Supongamos que un reporte necesito mostrar los datos de un proveedor
detallando la venta de sus articulos, agrupado por la categoria de los
mismos y con el saldo de su cuenta corriente.

En este ejemplo bastante básico por cierto, nos encontramos con la Entidad
Proveedor, con la entidad Cuenta Corriente, con la entidad Artículos, con
la entidad Categoria de los artículos, y hasta con 4 o 5 entidades más.
Entonces la duda puntual es, cómo hago para devolver una coleccion de
entidades con semejante complejidad?

Ahora, si solo necesito devolver un listado de clientes para llenar una
lista, bueno, es mucho más simple, porque simplemente "bindeo" la
List<Cliente> al datasource que necesito y listo.

Ojo, no quiero que se me malinterprete y digan "al final pide consejo pero
hace lo que quiere" realmente valoro la opinion de todos, porque de todos
algo se aprende, y pienso que es bueno generar discusión con respeto con
temas que creo nos pueden pasar a la mayoría.

Lo que sucede es que seguramente, debido a mi inexperiencia, no alcanzo a
dimensionar esa inconsistencia y falta de homogeneidad, los dataTable son lo
más parecido al Recordset de VB6 ADO donde yo levantaba los datos de la BD y
trabajaba con cada uno de los campos con mucha flexibilidad.

En nuestro modelo (y me imagino que en el de muchos que se dedican a
aplicaciones de gestion) las consultas o los datos son necesarios extraerlos
de muchas tablas y me encontre con la dificultad de encontrar una coleccion
de entidades que pueda representarme lo que estoy buscando.

Supongamos que un reporte necesito mostrar los datos de un proveedor
detallando la venta de sus articulos, agrupado por la categoria de los
mismos y con el saldo de su cuenta corriente.

En este ejemplo bastante básico por cierto, nos encontramos con la Entidad
Proveedor, con la entidad Cuenta Corriente, con la entidad Artículos, con la
entidad Categoria de los artículos, y hasta con 4 o 5 entidades más.
Entonces la duda puntual es, cómo hago para devolver una coleccion de
entidades con semejante complejidad?

Ahora, si solo necesito devolver un listado de clientes para llenar una
lista, bueno, es mucho más simple, porque simplemente "bindeo" la
List<Cliente> al datasource que necesito y listo.

Ojo, no quiero que se me malinterprete y digan "al final pide consejo pero
hace lo que quiere"