Últimos mensajes - Powered by IBM

Palabras claves

Trabajo con clases de Negocio

26/09/2008 - 17:04 por Guillermo Peralta | Informe spam

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

Siga el debate

31 respuestas

Tengo una respuesta

Preguntas similare

Mostrar todos los temas similares

Leer las respuestas

#26 Juan Diego Bueno

30/09/2008 - 23:02 | Informe spam

Hola Alfredo:

"Alfredo Novoa" escribió en el mensaje de
noticias:1s85hxo44ne24.ezcykph3rcgv$

El Tue, 30 Sep 2008 16:42:24 +0200, Alfredo Novoa escribió:

Antes de insertar una fila en mi "DataTable" intento
insertarla en la base de datos.

Pero por supuesto esto lo hace automáticamente sin que yo tenga que hacer
nada.

Me gusta esa idea, me la apunto. Yo normalmente en una inserción, lo que
hago es crear un datatable sin filas, pero con el esquema; le añado la fila
y mando cambios al SGBD haciendo el update sobre el dataadapter. Cuando
vulnera alguna restricción, la capturo y en función del tipo, muestro el
mensaje de error, que es parecido a lo tuyo, pero a la inversa. Lo que nunca
me ha entusiasmado de este método es que hay que esperar a que el usuario
pulse el botón de grabar cambios, cuando lo suyo sería que con cada cada
validación de control se hiciera un intento de inserción/actualización
contra el sgbd. Supongo que eso podría implementarse en segundo plano para
que no sufriera mucho el interfaz de usuario, dando una serie de campos
mínimos predefinidos en el caso de una inserción (me refiero a que si aún no
hemos puesto un campo obligatorio en nuestro formulario, no mande el insert
que a priori daría un fallo seguro). ¿Cómo lo véis?

Saludos

Responder a este mensaje

#27 Alfredo Novoa

01/10/2008 - 00:36 | Informe spam

Hola Juan Diego,

El Tue, 30 Sep 2008 23:02:19 +0200, Juan Diego Bueno escribió:

Me gusta esa idea, me la apunto.

Bueno, por supuesto no es idea mía sino que estoy copiando algunas de las
cosas buenas que tenía Delphi. Y supongo que el viejo Visual Basic haría
igual.

Yo normalmente en una inserción, lo que
hago es crear un datatable sin filas, pero con el esquema; le añado la fila
y mando cambios al SGBD haciendo el update sobre el dataadapter. Cuando
vulnera alguna restricción, la capturo y en función del tipo, muestro el
mensaje de error, que es parecido a lo tuyo, pero a la inversa. Lo que nunca
me ha entusiasmado de este método es que hay que esperar a que el usuario
pulse el botón de grabar cambios,

Y parece más trabajoso, a mi si me falla la actualización la línea
simplemente sigue en modo de edición. Aunque yo tengo el problema de que el
usuario tiene que cambiar de línea o de pulsar el botón de grabar para
grabar los cambios. Normalmente paso a la siguente línea con un Enter o
dándole a la flecha para abajo.

cuando lo suyo sería que con cada cada
validación de control se hiciera un intento de inserción/actualización
contra el sgbd.

Yo no estoy muy seguro de que valga la pena hacer eso siempre, sobre todo
en el caso de la inserción por lo que comentas de que pueden saltar muchos
errores simplemente por que la linea no está acabada. Hay cosas que se
pueden validar fácilmente en el "DataTable" como por ejemplo las claves
externas que te las puedes traer automáticamente de la base de datos y
también la comprobación del tipo de datos.

Si por alguna razón quiero que el SGBD me valide a nivel de campo pues
fuerzo el envío de los datos usando un evento del control visual, pero no
es muy frecuente.

Por supuesto todas las validaciones que se hagan en la aplicación hay que
repetirlas en el SGBD :-)

Supongo que eso podría implementarse en segundo plano para
que no sufriera mucho el interfaz de usuario, dando una serie de campos
mínimos predefinidos en el caso de una inserción (me refiero a que si aún no
hemos puesto un campo obligatorio en nuestro formulario, no mande el insert
que a priori daría un fallo seguro). ¿Cómo lo véis?

Yo envío los datos al servidor cada vez que se acaba una línea usando ADSL,
y es prácticamente instantaneo. A no ser que te pongas a mandar fotos
gordas, claro. Creo que un compañero mío arregló eso mandando las fotos en
un segundo plano, tengo que preguntarle como lo hizo.

Saludos

Responder a este mensaje

#28 Alfredo Novoa

01/10/2008 - 00:46 | Informe spam

Hola Pedro,

El Tue, 30 Sep 2008 16:56:00 -0400, Pedro escribió:

Si en un form o pagina usas un DataSet sin tipo y le agregas datatables con
o sin tipo eso es lo mas simple que puede ser.

Yo a veces uso un truquillo cutre con los "DataTables" sin tipo, que son
los únicos que uso. Y es que para no equivocarme al teclear el nombre de
los campos a veces defino unas constantes con los nombres y así también me
funciona el "intellisense".

En lugar de:

linea["Tarifa"]=cabecera["Tarifa"];

hago

const string Tarifa="Tarifa";

...

linea[Tarifa]=cabecera[Tarifa];

Con esta chorrada supero uno de los supuestos mayores inconvenientes de los
datatables sin tipo.

Está claro que te puedes equivocar y poner el nombre de un campo que no
pertenezca a esa tabla, pero para eso ya hay que estar muy en las berzas
:-)

Saludos
Alfredo

Responder a este mensaje

#29 Alfredo Novoa

01/10/2008 - 01:01 | Informe spam

Hola Jesus,

El Tue, 30 Sep 2008 17:29:53 +0200, Jesús López escribió:

No estaría mal ver esa implementación de IBindingList en CodeProject o en
CodePlex por ejemplo.

Desgraciadamente no lo tengo tan fácil por que es parte de un SGBD que
estoy haciendo y que aun no está como para que lo use cualquiera, y tendría
que cambiar bastantes cosas para que funcionase con SQL Server u Oracle.
Con MySQL ya ni de coña.

Saludos

Responder a este mensaje

#30 Pedro

01/10/2008 - 01:20 | Informe spam

Con esta chorrada supero uno de los supuestos mayores inconvenientes de
los
datatables sin tipo.

Asi es, yo tampoco le veo gran problema a estas clases sin tipo, si no que
por el contrario uno gana la ventaja de poder generalizar (y simplificar) el
código reusable y olvidarse de esos pésimos generadores de código que hay
por ahí (incluyendo el de los datasets tipados y el propio linq).

linea[Tarifa]=cabecera[Tarifa];

Está claro que te puedes equivocar y poner el nombre de un campo que no
pertenezca a esa tabla, pero para eso ya hay que estar muy en las berzas
:-)

Eso está muy bien. Y hasta puedes usar alguna convención en la notación para
reducir la posibilidad de confusión:
const string fldTarifa="Tarifa";
linea[fldTarifa]=cabecera[fldTarifa];

Es que hay gente por ahí que desde que le hablan de "untyped" creen que se
acaba el mundo y eso no es tan así.

"Alfredo Novoa" escribió en el mensaje
news:14m1h94vs3rlf.1jfeajjligazo$

Hola Pedro,

El Tue, 30 Sep 2008 16:56:00 -0400, Pedro escribió:

Si en un form o pagina usas un DataSet sin tipo y le agregas datatables
con
o sin tipo eso es lo mas simple que puede ser.

Yo a veces uso un truquillo cutre con los "DataTables" sin tipo, que son
los únicos que uso. Y es que para no equivocarme al teclear el nombre de
los campos a veces defino unas constantes con los nombres y así también me
funciona el "intellisense".

En lugar de:

linea["Tarifa"]=cabecera["Tarifa"];

hago

const string Tarifa="Tarifa";

...

linea[Tarifa]=cabecera[Tarifa];

Con esta chorrada supero uno de los supuestos mayores inconvenientes de
los
datatables sin tipo.

Está claro que te puedes equivocar y poner el nombre de un campo que no
pertenezca a esa tabla, pero para eso ya hay que estar muy en las berzas
:-)

Saludos
Alfredo

Responder a este mensaje

Ads by Google

Hacer una preguntaSiguiente

Tengo una respuesta

1 2 3 4 5 6 7

Busqueda sugerida