¿Programo bien?

eso es cierto, el sql standard suele ser idéntico, los store proc ya es otra
cosa, solo he visto algo de oracle y sqlserver, y la verdad es que estás en
lo cierto, ahora te entiendo.

;) son dos formas distintas de plantearlo! al final el usuario solo se
acuerda de ti el día que le falla el ordenador (que no tiene porque ser tu
aplicación)

Hola Alfredo:

¿ Podrías aclararme lo de objetos que mapean una fila ?

Gracias

No se puede mapear una tabla con una clase por que es absurdo, lo que

se hace es mapear una tabla con un objeto de tipo colección.

Objeto de tipo colección, pero de qué? de objeto de un tipo de clase que
mapea una tabla ?

No, de objetos que mapean a una fila.

No estarás diciendo lo mismo que dices que es absurdo?

Es que no es lo mismo, es muy distinto.

On 31 ene, 20:44, Alfredo Novoa wrote:

On 31 Jan 2007 10:36:43 -0800, "Paco Ferre"
wrote:

>Hola, yo no diría que está mal, solo que es mucho trabajo...

Mucho trabajo significa menos tiempo y menos dinero y eso está muy muy
mal :-)

A no ser que cobres por horas, claro, y de eso hay mucho.

>Por tanto el sistema está basado en una clase BaseNegocio de la que
>heredan todos los objetos de negocio de la aplicación.
>...

>Por tanto la traducción de:
> miCliente.Dni = txtDni.Text;
> miCliente.Nombre = txtNombre.Text;
> miCliente.Grabar();

>sería (aunque ya ni necesito hacerlo así):
> miCliente["Dni"] = txtDni.Text;
> miCliente["Nombre"] = txtNombre.Text;
> miCliente.Grabar();

O sea, que esto es todavía peor.

Te pongo aquí el código que escribo yo para hacer eso:

>Pero con esto evito hacer los get/set con los 20 campos y además el
>this["PuedeSerDeCualquierCosaAunqueNoSeaUnCampo"]

Y yo me evito crear las "clases de negocio" y el asignar las
propiedades a mano.

Si quieres asignar propiedades a mano por código, cosa que no es nada
recomendable, entonces puedes usar un dataset tipado y el VS te crea
todos los gets y sets automáticamente.

>BaseNegocio acaba haciendo un montón de trabajo (mucho foreach para
>leer, guardar, crear, eliminar, buscar, permisos de usuario...) que no
>hay que programar una y otra vez en las clases "hijas" y para el resto
>del "trabajo" existen métodos virtuales que se pueden sobreescribir en
>cada clase.

Yo no tengo que escribir nada de código para todas estas cosas.
Simplemente asignar algunas propiedades en los componentes.

>(Obviamente existe un mecanismo para poblar una colección de objetos a
>partir de un DataTable, y muchas cosas más).

Pero si ya tienes los datos en un DataTable, para que quieres otra
colección de objetos. El DataTable ya es una colección de objetos que
además permite el "DataBinding".

>Aparte de esto, para la interacción con el usuario, existen controles
>de usuario que se encargan de leer y escribir datos en las clases de
>negocio antes de ser guardadas, o sea controles que heredan o son
>compuestos de; TextBox, ComboBox, CheckBox, HyperLink, Button,
>LinkButton, DataGrid, DataList, UserControl...

Yo puedo usar los controles de .NET sin cambiarles nada.

>No digo que sea perfecto, ni que no me haya causado problemas. Pero
>estoy contento ya que en cada nuevo proyecto, solo tengo que
>preocuparme de lo realmente importante de la aplicación, o sea, de
>todo menos la "fontanería", jeje.

Pues yo veo un montón de fontanería innecesaria.

>Por otro lado también es una gozada encontrar un error y saber que
>solo tengo que arreglarlo en la clase o el control base para que no se
>vuelva a producir en cualquier otra parte de la aplicación.

Para mi es una gozada el no tener que crear un montón de código que
luego puede fallar.

Saludos

Hola Alfredo,

Creo que has llegado a conclusiones poco acertadas a partir de lo que
he escrito.
Y además no dices nada concreto de cómo haces las cosas.

Te pongo aquí el código que escribo yo para hacer eso:

¿Donde?, ¿has adjuntado algún archivo?

Y yo me evito crear las "clases de negocio" y el asignar las
propiedades a mano.

Que haya escrito estas líneas para explicar la diferencia de uso con
la del compañero Alberto:

miCliente.Nombre = txtNombre.Text;
miCliente["Nombre"] = txtNombre.Text;

No significa que tenga que escribirlo "a mano" para cada uno de los
campos, existe un mecanismo que hace el trabajo (y no es un generador
de código).



Sobre esto que dices:

Yo no tengo que escribir nada de código para todas estas cosas.
Simplemente asignar algunas propiedades en los componentes.

Pero despues:

Yo puedo usar los controles de .NET sin cambiarles nada.

¿Podrías explicar cómo?, no me digas que usas el Wizard de Visual
Studio ;D


Y por último:

Si quieres asignar propiedades a mano por código, cosa que no es nada
recomendable, entonces puedes usar un dataset tipado y el VS te crea
todos los gets y sets automáticamente.

Como entiendo que no los usas, puedo machacarles un poco a estos de
Microsoft, jeje, los datasets tipados son un montón de líneas de
código inútiles. Y ya visto que Crystal Reports (alias
MiraQueTieneNarices) los pide para trabajar, pues más razón tengo.


Sobre los triggers y los SPs decir que tienes razón en decir que no
conviene usarlos mucho, pero en mi caso el motivo es por comodidad.
Los triggers hace mucho tiempo que no los uso, me gusta tener el
código de "negocio" en un mismo sitio.
Y para los SPs, pueden ser útiles en consultas muy complejas (aunque
también creo que una consulta compleja es síntoma de un mal diseño de
base de datos), o para consultas que no van a cambiar nunca y son muy
utilizadas.

Alfredo, ¿no serás de Madrid o periferia?, la verdad es que sería
interesantísimo quedar un grupo, escuchar distintas opiniones y pensar
en nuevas ideas.

Saludos,

Paco Ferre

¿Y dices que C# es de bajo nivel?
"Alfredo Novoa" escribió en el mensaje
news:

On Thu, 1 Feb 2007 00:24:41 +0100, "Carmelo J. Morales Muñoz"
wrote:

Destrás de la capa de presentación ya solo está el usuario.

Hecha la capa de negocio, hacer un interface
para windows o web me supone poco esfuerzo...y por no hablar de la
extrema
claridad del código.

Ya, y a mi hacer la capa de negocio dentro del SGBD me supone mucho
menos esfuerzo que a alguien que la programe en un lenguaje de bajo
nivel no orientado a bases de datos como C#.

Eso dependerá de la complejidad de las reglas de negocio porque puede
rendundar en baja optimización

Cuanta más complejidad más se gana utilizando un lenguaje de alto
nivel.

Saludos