Sr's. Gurus: Entidades??

Hace tiempo que sacaron una versión para .NET y acaban de sacar la
segunda.

Lo miraré!!

Y en mi programa no deberé tener una clase equivalente a esa entidad??

¡Exacto!

Hay muchas razones por las que no debe de haberla.

Una tabla SQL es una variable de tipo colección, se parece un poco a
un "array" de C#, y es totalmente diferente de una clase que es un
tipo de datos.

Por ejemplo una tabla de clientes representa al conjunto de clientes
de una empresa en un momento dado, es decir varía con el tiempo. Pero
una clase Cliente es estática, siempre es igual. Es decir, que de
equivalentes no tienen nada.

Pero tu solución tiene el problema de las conexiones con la BBD y a lo mejor
no hace falta que se al aultimiiisima versión sino que valdría con un
"snapshot" para hacer el informe o lo que sea, por ejemplo puedo controlar
que 2 usuarios no acceden a modificar la misma factura al tiempo, esto con
un SGBD no da "problemas" pero a lo mejor sí en la vida real. En mi programa
basta con marcar la factura como bloqueada y en paz, ya no pueden acceder
los 2 a lo mismo

Para representar una tabla de clientes con la clase Cliente lo que
necesitas es una variable de tipo colección de Cliente que va a ser
típicamente una lista enlazada unidimensional.

O sea que has empleado un montón de trabajo para conseguir algo mucho
menos potente y manejable de lo que ya tenías: la tabla.

Bueno tanto como más manejable... es mucho más natural obj.campo que
rd.fields("campo") que además te puedes equivocar al escribirlo

Las tablas se pueden unir, proyectar, juntar, resumir, etc utilizando
sencillas instrucciones SQL. Con la lista de objetos Cliente no se
puede hacer nada de eso y hay que hacerlo todo a pedales a base de
mucho código.

Pero sí puedo cargar esa colección a base de hacer esas cosas en la base de
datos y traerme lo que me interese (otro snapshot). En cuanto al código te
doy la razón por eso quiero automatizarlo

Cuando insertas un registro en la tabla de clientes, el SGBD
automáticamente va a comprobar todas las restricciones de integridad
(reglas de negocio): claves candidatas, claves externas, aserciones,
triggers, etc. Cuando creas un nuevo objeto Cliente y lo añades a la
colección te toca hacer todas las comprobaciones a pelo.

Bueno yo la verdad las realizo en 3 sitios (uno por capa:D) en la capa de
interfaz y así cuando el clietne trata de meterme datos inválidos casca,
otro en mis objetos de entidad (que según tu filosofía sobran) y otro en la
capa de control (aquí en la base de datos las restricciones de campos y las
relaciones entre objetos en unas clases de control)

Es más los SGBD se crearon precisamente para poder eliminar este tipo
de entidades de las aplicaciones.

No es lo que me han enseñado ni me enseñan pero eso no quiere decir que yo
tenga razón, me informaré con los links que me dices y luego ya analizaré lo
que más me convence...

Imagínate que tienes que hacer un informe de rentabilidad. Si usas las
clases propias vas a tener que traerte prácticamente todos los
registros de la base de datos, ir recorrendolos todos, ir relacionando
los datos de las distintas tablas e ir acumulando valores. Un trabajo
de chinos que va a provocar un montón de tráfico de red.

Si lo haces con SQL simplemente tienes que especificar el resultado
que deseas y el SGBD se encarga de todo lo demás enviando a la
aplicación los resultados ya listos para presentar.

Otro ejemplo: imagínate que tienes que subirle el sueldo un 5% a los
empleados de paises de la Union Europea con más de 10 años de
antigüedad. Con los objetos propios tendrías que traerte todos los
registros de empleados mirar la antiguedad y el pais, comprobar si el
pais es de la UE, subirles un 5% y después enviar una orden de
actualización al SGBD. Si lo haces en SQL le mandas una linea de nada
al servidor, este se ocupa de todo y lo hace muchísimo más rápido sin
apenas tráfico de red.

Bueno pero es que tendríamétodos o clases que me ejecutan esas SQL y por lo
tanto otra vez líneas de código repetitivo

Vamos, que con lo de los objetos propios el volumen de código se puede
multiplicar tranquilamente por 5 o por 10 y además puede ir mucho más
lento. Y si quieres acelerarlo a base de cachés y cosas de esas pues
otra vez a escribir un montón de código, y tampoco vas a conseguir
maravillas.

El volumen de código sí se multiplica pero creo quela escalabilidad es mayor
y la seguridad en la aplicación también

o
dices de tratar los datos de manera inconexa sin estar agrupado en ningún
objeto?

Esto no lo entiendo.

Me refería que rescatabas de la tabla y lo ponias en variables
independietnes pero veo que lo dejas en la tabla

Eso se puede hacer dinámicamente. No hace falta generar código. Además
así la aplicación se podría adaptar a muchos cambios en el diseño
lógico de la base de datos sin necesidad de recompilación.

Sí tienes razón se puede hacer en tiempo de ejecución pero si se hace en
tiempo de compilación el rendimiento mejora e incluso podría incluir esas
select, insert y demás dentro de la base de datos.

El rendimiento no lo es todo. Hay que buscar un equilibrio entre
esfuerzo y rendimiento. Si para lograr un 5% más de rendimiento tienes
que trabajar el triple está claro que no vale la pena. Es mucho más
rentable gastarte 4 duros más en un equipo más rápido.

Te doy la razón, pero meter en un cualquier programa reflectividad y
análisis de la estructura de la bbdd sólo para que sea escalable no me
parece la mejor solución. Por eso prefiero obtener ya las estructuras con
anterioridad a la compilación que además de la casualidad de la eficiencia
(no lo buscaba pero ya que lo encuentro...)

Efectivamente mi solución tiene el problema de la recompilación pero
quizás
con sustituir algunas dll podría arreglarse (no evita el problema pero lo
minimiza)

Ya, lo que pasa es que esto no es nada comparado con el problema de la
gestión de la información de forma procedimental desde las
aplicaciones.

Bueno lo de las entidades no lo discuto tengo que informarme más!
Lo de gestión procedimental sí porque tengo unas clases que actuan de
interface con la BBDD (lo que te decía con el ejemplo de los sueldos)

Si intentases implementar por ejemplo un sistema de gestión de
almacenes o gestión comercial minimamente realista, utilizando las
listas de objetos en memoria te darías cuenta enseguida de lo
engorroso que es.

Hombre no lo gestiono en memoria lo gestiono en el motor de la bbdd que es
más eficiente y está preparado para eso, esas clases sólo son usadas para
interacción con otros sistemas (como puede ser el usuario) y no para tratar
tropeles de información

Quiero insertar un pedido entero en la BBDD o no insertar nada, los campos
serían nombre cliente, nº de pedido y fecha. Los campos de cada línea del
pedido sería nombre producto, id del producto, cantidad y precio unitario.

¿Cómo puedo insertar todo eso en la bbdd y encima obtener el nº del pedido
(el de la factura)?

Si es un pedido que está fijo en algún sitio ejecutas un script SQL
con los insert y luego haces una consulta para obtener los números de
factura que supongo que será un simple campo autoincrementado.

Y ese script no lo tienes que llamar pasandole todos los datos desde la
aplicación?pues una clase que quizás sea parecida a la que usas para
insertar también las lineas (creo)

En caso de que el número de factura sea más complejo lo puedes
calcular con un "trigger".

En caso de que sea una aplicación con una interfaz gráfica solo
necesitas asociar las tablas de la base de datos a los controles del
formulario y listo. Eso en Delphi se hace muy fácilmente.

No todos los controles son asociables directamente (por desgracia)

yo para eso necesito una clase pedido, otra lineapedido,
sus correspondientes tablas, abrir una transacción, llamar a la función de
inserción de la clase pedido y luego llamar N veces a la función de
insertar
líneas para luego cerrar la transacción.

Yo eso lo hago sin una linea de código :)

Pero como llamas al script SQL?

Si se puede hacer mediante un SP como sería?te agradecería que pusieras el

Los SP son la peor forma de implementar algo en un SGBD, se deben de
usar solo cuando no haya una forma declarativa de hacerlo. Para hacer
lo que dices no veo necesidad de usar SPes, excepto quizás para
generar el número de factura, ya que los "triggers" son simplemente un
caso especial de SPes.

ombre lo decía por la transaccionalidad entre el pedido y el detalle del
pedido 8esto último no me has dicho como resolverlo)

Espero no abusar demasaido de tu ayuda

No te preocupes.


Saludos

Me alegro que no te moleste ayudar;)

Datase no tipados
Solo me la planteo si la estrucutura de los datos cambia a menudo

Esto pasa casi siempre.

Execelente rendimiento, los dataset son pequeños, no llevan metadatos

Si llevan metadatos, hay un montón de cosas que se le pueden preguntar
a un dataset no tipado.

Menos que los tipado o no? Por supuesto que llevan.

Dataset tipados
Es la recomendable desde mi punto de vista
Ideal si solo movemos datos
Ideal si los datos tienen más peso que el comportamiento
Ideal para enlazar los datos a la capa de presentación

Lo malo es el trabajo que cuesta crearlos y la rigidez que dan a la
aplicación.

Trabajo le llamas a arastrar y soltar? Visual Studio soporta crear dataset
sin escribir una sola linea de codigo.

Aunque creo haber leido que el Data Access Application Block ese
permite crear datasets tipados automáticamente con FillSchema

Yo creo los datasets automáticamente siempre que puedo, ahorra un
montón de trabajo.

Objetos propios
Ideal cuando solo con datos no vale, sino que los datos llevan
asociado
un comportamiento

¿Esto lo has probado o lo dices de "oidas"?

Siempre hablo de oidas. En realialida no he escrito ni una sola linea de
código en C#.

Los datos siempre llevan asociado un comportamiento. A esto se le
suele llamar "reglas de negocio".

Las reglas de negocio no se mueven con los datos, en una arquitectura
correctamente diseñada, las reglas de negocio estan aisladas de los datos y
la capa de presentación solo necesita los datos, no las reglas de negocio.
La capa de presentación no debe saber nada de las reglas de negocio.

Para implementar las reglas de negocio lo ideal es el enfoque
declarativo de los SGBD modernos.

Por ejemplo si un comportamiento de los datos es que no puede haber
dos proveedores con un mísmo número de proveedor, esto se soluciona
fácilmente con una clave primaria, en lugar de andar escribiendo
código para ir recorriendo todos los objetos proveedor mirando si ya
existe ese código.

Una pena que las reglas de negocio no sean tan simples como las que
planteas.

Ideal si los datos determinan el comportamiento del cliente, ya que
los
objetos llevan datos y comportamiento

Sin sentido.

Exiten sistemas complejos en los que la capa de presentación va mucho más
alla de simplemente mostrar un grid con datos. Conozco un proyecto sobre un
sistema de simulación en el que un servidor compone unos XML y crea un
assembly que envia al cliente.

Otro ejemplo es http://www.terrariumgame.net/terrarium

Rigida si la estrutura de los datos cambia a menudo
Menos rendimiento
Más dificultad para enlazar los datos a los controles

Es decir, que es un desastre.

Una vez más se demuestra que no existen las balas de plata...

Si existen. Hay muchas balas de plata que usamos cada día, pero
estamos tan acostumbrados a ellas que no nos damos cuenta de que no
existen desde siempre.



Por ejemplo, los lenguajes de programación son una bala de plata.
Nunca más se ha seguido desarrollando aplicaciones utilizando código
máquina (el ensamblador es un lenguaje), ni enchufando y desenchufando
cables.

Los lenguajes de alto nivel son misiles de plata, no valas ;)

Repasate el antipatron silver bullet y verás de que hablo.

no hay
solución que funcione siempre.

Las balas de plata tampoco funcionan siempre, con Drácula no valen :)

Esto último es broma.


Saludos

Un saludo
Rodrigo Corral González [MVP]

FAQ de microsoft.public.es.vc++
http://rcorral.mvps.org

On Fri, 29 Oct 2004 11:17:23 +0200, "Rodrigo Corral [MVP]"
wrote:

Execelente rendimiento, los dataset son pequeños, no llevan metadatos

Si llevan metadatos, hay un montón de cosas que se le pueden preguntar
a un dataset no tipado.

Menos que los tipado o no? Por supuesto que llevan.

Ah, menos mal, pensé que habías dicho lo contrario ;-)

Trabajo le llamas a arastrar y soltar? Visual Studio soporta crear dataset
sin escribir una sola linea de codigo.

Bueno, en realidad yo solo uso ADO.NET para aplicaciones para Pocket
PC y con el Compact Framework no se puede.

Siempre hablo de oidas. En realialida no he escrito ni una sola linea de
código en C#.

No se si lo dirás de coña, pero cualquiera que haya probado lo de los
objetos de negocio y el "object relational mapping" se da cuenta de
que es un desastre, que hacer cualquier chorrada da un montón de
trabajo y el rendimiento es muy pobre.

Los datos siempre llevan asociado un comportamiento. A esto se le
suele llamar "reglas de negocio".

Las reglas de negocio no se mueven con los datos

Sin sentido.

, en una arquitectura
correctamente diseñada, las reglas de negocio estan aisladas de los datos

Reglas de negocio es sinónimo de diseño de base de datos. Diseñar una
base de datos consiste en especificar las reglas de negocio.

Garantizar las reglas de negocio es una de las funciones principales
de un SGBD. Eso te lo enseñan en la primera clase.

Las reglas de negocio forman la base de datos intensional (metadatos,
las reglas de negocio son los metadatos), y los datos del "dominio"
del sistema constituyen la base de datos extensional.

la capa de presentación solo necesita los datos, no las reglas de negocio.

Claro, la presentación es responsabilidad de la aplicación y las
reglas de negocio son responsabilidad del SGBD. Las funciones de las
aplicaciónes cliente son la presentación y la comunicación.

La capa de presentación no debe saber nada de las reglas de negocio.

La capa de presentación y comunicación debe ser la aplicación cliente,
la capa de reglas de negocio debe ser el SGBD y la capa de datos es la
base de datos que suele estar almacenada en discos.

Nunca hay que confundir a las bases de datos con los sistemas de
gestión de bases de datos, que también son un conjunto de
aplicaciones.

Es más, los "stored procedures" también son aplicaciones. Los SGBD
deben de ser extensibles y poder ejecutar aplicaciones.

Parece que hay mucha tendencia a seguir pensando en aplicaciones
monolíticas en lugar de en sistemas de información que son conjuntos
de aplicaciones especializadas que funcionan de forma coordinada.

Para implementar las reglas de negocio lo ideal es el enfoque
declarativo de los SGBD modernos.

Por ejemplo si un comportamiento de los datos es que no puede haber
dos proveedores con un mísmo número de proveedor, esto se soluciona
fácilmente con una clave primaria, en lugar de andar escribiendo
código para ir recorriendo todos los objetos proveedor mirando si ya
existe ese código.

Una pena que las reglas de negocio no sean tan simples como las que
planteas.

¡Que barbaridad!

Lo que he mostrado es una regla de negocio sencilla, pero es una regla
de negocio.

Y además es un tipo de regla de negocio muy muy frecuente.

Cualquier regla de negocio puede expresarse de forma declarativa, y
cualquier SGBD puede implementar cualquier regla de negocio
computable.

Ideal si los datos determinan el comportamiento del cliente, ya que
los
objetos llevan datos y comportamiento

Sin sentido.

Exiten sistemas complejos en los que la capa de presentación va mucho más
alla de simplemente mostrar un grid con datos.

Pero las reglas de negocio siguen siendo responsabilidad del SGBD.

Conozco un proyecto sobre un
sistema de simulación en el que un servidor compone unos XML y crea un
assembly que envia al cliente.

¿Y?

Otro ejemplo es http://www.terrariumgame.net/terrarium

Un ejemplo de sistema de información compuesto por un SGBD (llamado
Terrarium Server) y un conjunto de aplicaciones (una aplicación
llamada Client).

A diferencia de los SGBD diseñados para los sistemas de gestión, como
SQL Server y Oracle, el Terrarium Server ese es un SGBD de propósito
específico, es decir que lleva las reglas de negocio puestas a capón
en el código y no puede usarse para otros propósitos.

Es evidente que los SGBD de propósito general son mucho más
convenientes, aunque la gran mayoría están diseñados para la gestión y
no van bien para otras cosas como los videojuegos o el CAD y no queda
más remedio que hacerlo todo a pedal.

Está claro que en un videojuego multijugador a través de Internet las
reglas de negocio deben de estar garantizadas por el servidor (el
SGBD), sino cualquiera podría manipular el cliente y romper las reglas
para hacer trampas.

Por supuesto los sistemas monolíticos también siguen existiendo y son
apropiados para casos muy sencillos.

Por ejemplo, los lenguajes de programación son una bala de plata.
Nunca más se ha seguido desarrollando aplicaciones utilizando código
máquina (el ensamblador es un lenguaje), ni enchufando y desenchufando
cables.

Los lenguajes de alto nivel son misiles de plata, no valas ;)

Pues mejor aun.

Repasate el antipatron silver bullet y verás de que hablo.

He encontrado muy poca información sobre eso.

Pero vamos, balas de plata haberlas hailas.

Los que se dedican a escribir libros sobre patrones deberían de
aprender algo sobre el patrón: Aplicaciónes-SGBD, y sobre los
antipatrones: "Gestiona los datos desde tu aplicación", y "Crea tu
propio SGBD".


Saludos

Muchas gracias a todos! ya estoy leyendo los links!
Pero ALfredo dice que es posible, crear dataset tipados a travez de
FillSchema, como es eso?? tenes algun ejemplo??

"Alejandro" wrote:

Buenas gente! espero no se aburran con esta "New Question".
Hace unas semanas estoy desarrollando un framework para una aplicacion,
tanto asp.net como windows forms, obviamente separada en capas (tranatando en
lo posible aplicar patrones de diseño), y utilizo, para el acceso a datos el
Data Acces Application Block, y me surgio una inquietud muy grande, con
respecto a las entidades. Es decir, los objectos que viejan entre las capas
(Proveedor, usuario, material, etc, etc).Ahora la inquitud es la siguiente:
que me recomiendan para la implementacion de entidades??
He probado con DS (DataSets) tipados, y con clase definidas por mi, se que
los dos andan, los he visto en varios sistemas, pero ... que es mejor??. Se
que hay muchos gurus dando vueltas por el foro, asi que espero alguna
recomendacion o algun link donde pueda subsanar esa duda.

Desde ya gracias!! Slds!
Alejandro.

On Sun, 31 Oct 2004 16:37:03 -0800, Alejandro
wrote:

Muchas gracias a todos! ya estoy leyendo los links!
Pero ALfredo dice que es posible, crear dataset tipados a travez de
FillSchema, como es eso?? tenes algun ejemplo??

Lo siento, me he equivocado, lo que ponía es que se pueden llenar con
FillDataSet.

Ya me parecía raro O:)


Saludos