Trabajo con clases de Negocio

Hola Guillermo,

El Mon, 29 Sep 2008 14:51:27 -0300, Guillermo Peralta escribió:

Puede ser, pero si yo necesito entrar univocamente a un cliente tengo que
hacerlo por su Identificador,

Pero un cliente puede tener varios identificadores, y normalmente los
tiene.

puede ser que los usuarios desde la interfaz
grafica ingresen por apellido y nombre, pero la misma interfaz grafica
debe
proveer medios tambien para poder recuperar ese ID (una columna oculta en
un
gridview, el SelectedValue de un ListControl, etc)

Es decir que primero necesitas encontrar el identificador utilizando una
clave real. Siempre vas a tener alguna clave real, así que es evidente que
el identificador artificial es prescindible, que es lo que quería decir
Jesús.

Saludos

Es que yo en el diseño de la BD tengo siempre un IdTabla que es un
identificador autonumerico que relaciona univocamente a un objeto de la vida
real (un cliente) con un registro dentro de un tabla en la base de datos.

Ahora bien, si ese cliente tiene otra clave natural (supongamos un Nro de
Documento) simplemente agrego una restriccion en el motor para que no me
permita duplicados.

Es posible que no sea la mejor de las soluciones pero puedo asegurar que es
perfectamente valida por el simple hecho de que a mi me sirve :)

Al principio de mi carrera no me terminaban de convencer los autonumericos,
pero luego me resultaron bastantes cómodos, y si están ahi porqué no
usarlos..

Hola Jesús, gracias por tu comentario

1) Es muy laborioso crear toda la infraestructura para todas las tablas y
relaciones que tienes en la base de datos, es decir crear todas las
clases de las entidades con todas sus propiedades, etc, además de crear
las clases necesarias para consultar y guardar los datos en la base de
datos. Sería necesario tener alguna herramienta para generarlas de forma
automática.

Sí, de hecho de tenemos escrito "codigo que escribe código" y genera las
clases correspondientes, obviamente no es un ORM completo pero nos sirve.

2) Queda cojo el tema de las consultas. Me refiero a por ejemplo
responder a preguntas como ¿qué clientes tienen algún domicilio en una
determinada ciudad?

Para esos casos yo pensaba simplemente tener una funcion
GetDomiciliosxCiudad (Entidades.Ciudad Ciudad) que devuelva un DataTable
con los resultados de la consulta SQL (realizada a través de SP)

3) No siempre es necesario cargar todas las propiedades de una clase (o
columas de una tabla).

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

4) La carga de una entidad por medio de su Id, puede resultar muy últil.
Pero los usuarios no suelen buscarlas por el Id sino por otros atributos,
que puede que se encuentren en otras tablas.

Puede ser, pero si yo necesito entrar univocamente a un cliente tengo que
hacerlo por su Identificador, puede ser que los usuarios desde la interfaz
grafica ingresen por apellido y nombre, pero la misma interfaz grafica
debe proveer medios tambien para poder recuperar ese ID (una columna
oculta en un gridview, el SelectedValue de un ListControl, etc)

Si estás interesado en crear clases de entidad que mapeen con las bases
de datos yo te recomendaría que empezaras usando herramientas ya
establecidas y usadas por mucha gente en vez de crearte tú tu propio
modelo. Podrías empezar por Entity Framework que es parte de .NET
Framework 3.5 SP1. O quizá podrías usar NHibernate.

He estado probando algunos, de hecho Cooperator Framework me gustó, pero
siento que generan demasido código que no necesito, por eso me gusta tener
control del codigo que hay en mi aplicación.

Saludos
Guillermo Peralta


"Jesús López" escribió en el
mensaje de noticias:u3n#

Mi opinión es que esos modelos son muy similares, y no veo ventajas o
inconvenientes claros para decidirse por uno o por otro. Sin embargo veo
algunos problemas graves:

1) Es muy laborioso crear toda la infraestructura para todas las tablas y
relaciones que tienes en la base de datos, es decir crear todas las
clases de las entidades con todas sus propiedades, etc, además de crear
las clases necesarias para consultar y guardar los datos en la base de
datos. Sería necesario tener alguna herramienta para generarlas de forma
automática.
2) Queda cojo el tema de las consultas. Me refiero a por ejemplo
responder a preguntas como ¿qué clientes tienen algún domicilio en una
determinada ciudad?
3) No siempre es necesario cargar todas las propiedades de una clase (o
columas de una tabla).
4) La carga de una entidad por medio de su Id, puede resultar muy últil.
Pero los usuarios no suelen buscarlas por el Id sino por otros atributos,
que puede que se encuentren en otras tablas.

Si estás interesado en crear clases de entidad que mapeen con las bases
de datos yo te recomendaría que empezaras usando herramientas ya
establecidas y usadas por mucha gente en vez de crearte tú tu propio
modelo. Podrías empezar por Entity Framework que es parte de .NET
Framework 3.5 SP1. O quizá podrías usar NHibernate.

Saludos:

Jesús López



"Guillermo Peralta" @SPAM.com.ar> escribió en
el mensaje news:uQsuek%

Hola que tal,
Les planteo una consulta acerca de cual es la manera que uds creen
conviente para realizar lo siguiente utilizando una metodologia en Capas
y Orientada a Objetos.

El planteo es tener una clase Cliente y un clase Domicilios como
propiedad de la primera que realizan el mapeo de la Base de datos a un
modelo OO

Cliente

IdCliente
Nombre
Domicilios


Domicilios
Calle
Numero


Hasta ahi todo bien. Ahora necesito tener una manera de cargar tanto los
datos del cliente como los de sus domicilios, eso lo implementaria a
traves de una clase de negocio llamada NegocioClientes


El 1º planteo es tener un metodo static dentro de NegocioClientes que
provea metodos de servicios para llevar a cabo las distintas acciones

Entidades.Clientes EntidadCliente = new Entidades.Cliente ( 123 );
//inicializo con el Id del Cliente

NegocioClientes.Fill (EntidadCliente ); //cargo los datos basicos del
Cliente
NegocioClientes.FillDomicilios (EntidadCliente); //cargo los
domicilios del cliente


//accedo a los datos del cliente de la siguiente manera
string Nombre = EntidadCliente.Nombre;

string Calle = EntidadCliente.Domicilios[0].Calle;



El 2º planteo es tener dentro de la clase de NegocioClientes un objeto
EntidadClientes como propiedad y disponer dentro de Negocio metodos para
la carga de estos datos:

NegocioClientes Cliente = new NegocioClientes ( 123); //inicializo
con el Id del Cliente

Cliente.Load (); //cargo los datos del cliente

Cliente.LoadDomicilios (); //cargo los domicilios

//accedo a los datos del cliente de la siguiente manera

string Nombre = Cliente.EntidadCliente.Nombre;

string Calle = Cliente.EntidadCliente.Domicilios[0].Calle;



Espero que se entiendan los distintos planteos, funcionalmente no
encuentro mayores diferencias entre uno y otro, y es por eso que me
encuentro un poco confundido en que metodología seguir.


Saludos
Guillermo Peralta

Hola Jesús, gracias por tu comentario

1) Es muy laborioso crear toda la infraestructura para todas las tablas y
relaciones que tienes en la base de datos, es decir crear todas las
clases de las entidades con todas sus propiedades, etc, además de crear
las clases necesarias para consultar y guardar los datos en la base de
datos. Sería necesario tener alguna herramienta para generarlas de forma
automática.

Sí, de hecho de tenemos escrito "codigo que escribe código" y genera las
clases correspondientes, obviamente no es un ORM completo pero nos sirve.

2) Queda cojo el tema de las consultas. Me refiero a por ejemplo
responder a preguntas como ¿qué clientes tienen algún domicilio en una
determinada ciudad?

Para esos casos yo pensaba simplemente tener una funcion
GetDomiciliosxCiudad (Entidades.Ciudad Ciudad) que devuelva un DataTable
con los resultados de la consulta SQL (realizada a través de SP)

3) No siempre es necesario cargar todas las propiedades de una clase (o
columas de una tabla).

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

4) La carga de una entidad por medio de su Id, puede resultar muy últil.
Pero los usuarios no suelen buscarlas por el Id sino por otros atributos,
que puede que se encuentren en otras tablas.

Puede ser, pero si yo necesito entrar univocamente a un cliente tengo que
hacerlo por su Identificador, puede ser que los usuarios desde la interfaz
grafica ingresen por apellido y nombre, pero la misma interfaz grafica
debe proveer medios tambien para poder recuperar ese ID (una columna
oculta en un gridview, el SelectedValue de un ListControl, etc)

Si estás interesado en crear clases de entidad que mapeen con las bases
de datos yo te recomendaría que empezaras usando herramientas ya
establecidas y usadas por mucha gente en vez de crearte tú tu propio
modelo. Podrías empezar por Entity Framework que es parte de .NET
Framework 3.5 SP1. O quizá podrías usar NHibernate.

He estado probando algunos, de hecho Cooperator Framework me gustó, pero
siento que generan demasido código que no necesito, por eso me gusta tener
control del codigo que hay en mi aplicación.

Saludos
Guillermo Peralta


"Jesús López" escribió en el
mensaje de noticias:u3n#

Mi opinión es que esos modelos son muy similares, y no veo ventajas o
inconvenientes claros para decidirse por uno o por otro. Sin embargo veo
algunos problemas graves:

1) Es muy laborioso crear toda la infraestructura para todas las tablas y
relaciones que tienes en la base de datos, es decir crear todas las
clases de las entidades con todas sus propiedades, etc, además de crear
las clases necesarias para consultar y guardar los datos en la base de
datos. Sería necesario tener alguna herramienta para generarlas de forma
automática.
2) Queda cojo el tema de las consultas. Me refiero a por ejemplo
responder a preguntas como ¿qué clientes tienen algún domicilio en una
determinada ciudad?
3) No siempre es necesario cargar todas las propiedades de una clase (o
columas de una tabla).
4) La carga de una entidad por medio de su Id, puede resultar muy últil.
Pero los usuarios no suelen buscarlas por el Id sino por otros atributos,
que puede que se encuentren en otras tablas.

Si estás interesado en crear clases de entidad que mapeen con las bases
de datos yo te recomendaría que empezaras usando herramientas ya
establecidas y usadas por mucha gente en vez de crearte tú tu propio
modelo. Podrías empezar por Entity Framework que es parte de .NET
Framework 3.5 SP1. O quizá podrías usar NHibernate.

Saludos:

Jesús López



"Guillermo Peralta" @SPAM.com.ar> escribió en
el mensaje news:uQsuek%

Hola que tal,
Les planteo una consulta acerca de cual es la manera que uds creen
conviente para realizar lo siguiente utilizando una metodologia en Capas
y Orientada a Objetos.

El planteo es tener una clase Cliente y un clase Domicilios como
propiedad de la primera que realizan el mapeo de la Base de datos a un
modelo OO

Cliente

IdCliente
Nombre
Domicilios


Domicilios
Calle
Numero


Hasta ahi todo bien. Ahora necesito tener una manera de cargar tanto los
datos del cliente como los de sus domicilios, eso lo implementaria a
traves de una clase de negocio llamada NegocioClientes


El 1º planteo es tener un metodo static dentro de NegocioClientes que
provea metodos de servicios para llevar a cabo las distintas acciones

Entidades.Clientes EntidadCliente = new Entidades.Cliente ( 123 );
//inicializo con el Id del Cliente

NegocioClientes.Fill (EntidadCliente ); //cargo los datos basicos del
Cliente
NegocioClientes.FillDomicilios (EntidadCliente); //cargo los
domicilios del cliente


//accedo a los datos del cliente de la siguiente manera
string Nombre = EntidadCliente.Nombre;

string Calle = EntidadCliente.Domicilios[0].Calle;



El 2º planteo es tener dentro de la clase de NegocioClientes un objeto
EntidadClientes como propiedad y disponer dentro de Negocio metodos para
la carga de estos datos:

NegocioClientes Cliente = new NegocioClientes ( 123); //inicializo
con el Id del Cliente

Cliente.Load (); //cargo los datos del cliente

Cliente.LoadDomicilios (); //cargo los domicilios

//accedo a los datos del cliente de la siguiente manera

string Nombre = Cliente.EntidadCliente.Nombre;

string Calle = Cliente.EntidadCliente.Domicilios[0].Calle;



Espero que se entiendan los distintos planteos, funcionalmente no
encuentro mayores diferencias entre uno y otro, y es por eso que me
encuentro un poco confundido en que metodología seguir.


Saludos
Guillermo Peralta

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)