Sobre Serialización

"Lo que tienes que hacer es mapear la tabla Empleado a la interfaz de
usuario usando algo del estilo de ADO.NET, aunque ADO.NET tampoco me
gusta un pelo."

Perdón por mi escaso conocimiento en el tema...
Si yo tengo una aplicación de 3 niveles, DataAccess ( a través de
webservices ), Business y UI ( trabajando en una aplicación de winforms ),
al hacer ese mapeo estoy brindando un acceso directo desde la BBDD a la
interfaz del usuario.
Y también el caso opuesto, los ingresos y modificaciones del usuario que se
insertarían en forma directa en la BBDD.

Eso no contradice presisamente el desarrollo en niveles?

Gracias por la aclaración que me puedas brindar.
Saludos cordiales.

Sergio Cossa
Argentina

"Alfredo Novoa" wrote in message
news:
On Mon, 14 Feb 2005 12:21:50 -0800,
wrote:

Voy a puntualizar:

- Sé que una cosa es una tabla Empleado y otra cosa la
clase Empleado. Pero para mi aplicación el concepto es el
mismo, utilizo la clase Empleado para representar en C# un
empleado en mi aplicación y la tabla Empleado para
persistencia de los datos de ese empleado.

Pues muy mal hecho. Los Sistemas de Gestión de Bases de Datos se
utilizan para muchas más cosas además de la persistencia. Eso te lo
explican en los primeros capítulos de cualquier texto serio de
introducción a los sistemas de bases de datos.

Los SGBD se utilizan para gestionar la información, y si la base de
datos tiene una tabla Empleado entonces la aplicación no necesita
ninguna clase Empleado, que solo serviría para complicar las cosas. Es
más, los SGBD se crearon entre otras cosas para eliminar la necesidad
de ese tipo de clases. Es una parte de todo el trabajo que nos ahorran
los SGBD.

Lo que tienes que hacer es mapear la tabla Empleado a la interfaz de
usuario usando algo del estilo de ADO.NET, aunque ADO.NET tampoco me
gusta un pelo.

Repito que tablas y clases son completamente diferentes. Eso que dices
de que para tu aplicación el concepto es el mismo no tiene sentido.

Para mim aplicación existe una correspondencia campos de
la tabla Empleado con propiedades clase Empleado

Entonces tu aplicación está mal diseñada.

No hay correspondencia entre los atributos de una tupla y las
propiedades de una clase.

(similar
a clase Dataset de una tabla que se puede obtener mediante
utilidad de VS.NET).

No, no es similar. En el caso de un DataTable de ADO.NET la
correspondencia se da entre una variable de tipo DataTable y una
tabla. En este caso estamos mapeando entre dos variables y no entre un
tipo y una variable. En este caso la correspondencia es en principio
aceptable.

Es una especie de ORM para mi,

El llamado Object Relational Mapping es un concepto totalmente
equivocado del que conviene apartarse lo más posible.

aunque conceptualmente no sea así, en la práctica, para mi
es útil y funcional.

Según con que lo compares. Si lo comparas con una aplicación bien
realizada la diferencia es brutal, pero si es la única forma de
trabajar que conoces pues entonces es normal que la encuentres útil.

No es que hacer las cosas así no funcione, sino que hay formas
infinitamente mejores de hacerlo.

- No utilizo SQL Server 2005, sino SQL Server 2000.
Desgraciadamente, o afortunadamente, no puedo utilizar
esas características.

Bueno, tendrías que preguntarte si realmente las necesitas. Las bases
de datos de gestión raramente necesitan tipos definidos por el usuario
(UDTes). Casi todo lo puedes resolver con los tipos predefinidos de
SQL: numeros, fechas, cadenas, etc.

Las entidades como Empleados se deben de modelar como tablas y no como
tipos escalares, y las propiedades de entidades como Empleados suelen
encajar bien con los tipos predefinidos de SQL.

Por esta razón se ha tardado tanto en incluir la posibilidad de crear
nuevos tipos en los SGBD comerciales: no hacen mucha falta para las
aplicaciones de gestión. Estas características son mucho más
necesarias para sistemas GIS o CAD.

Además, es posible que en el futuro tampoco pueda
utilizarlas, puede darse el caso que utilice Oracle,

Oracle tiene características parecidas desde mucho antes que SQL
Server.

MySQL, ODBC, etcétera.

MySQL es un SGBD muy pobre. Y eso las últimas versiones. A las
versiones anteriores ni si quiera se las podía considerar como un
SGBD. Yo no recomendaría MySQL para un sistema de gestión serio por
muy barato que sea.

- Siempre he pensado que la confusión se aclararía en
estos foros, leyendo documentación de Internet, etcétera.

Pues desgraciadamente eso no suele ocurrir, y menos en el mundo de las
bases de datos.

Además esto no es un tema de documentación de productos comerciales,
es un tema de fundamentos de la informática. Sobre eso no suele haber
mucho material de calidad disponible en la red. La mayoría de la
información que hay en la red está escrita por gente que está
intentando venderte sus productos.

Desgraciadamente no puedo distinguir qué personas que
escriben de base de datos tienen idea y cuáles no.

Pues te doy enlaces sobre la gente que más sabe sobre esto para que
puedas comparar:

www.dbdebunk.com

El mejor libro con diferencia sobre introducción a la teoría de bases
de datos que hay en el mercado es este:

http://www.agapea.com/Introduccion-...11521i.htm

Es una lectura imprescindible para cualquiera que quiera desarrollar
sistemas de gestión de forma seria.


Saludos

On Tue, 15 Feb 2005 11:53:06 -0300, "Sergio Cossa"
wrote:

Perdón por mi escaso conocimiento en el tema...

No hay nada que perdonar.

Si yo tengo una aplicación de 3 niveles, DataAccess ( a través de
webservices ), Business y UI ( trabajando en una aplicación de winforms ),

El nombre que se le da a los niveles ya indica que es probable que las
cosas se estén haciendo mal.

Por ejemplo lo de "DataAccess" debería de ser DBMS Access.

Las peticiones que se le hacen al DBMS deberían de ser en el lenguage
del SGBD (SQL normalmente).

El nivel Business, también llamado de lógica de negocio debe de estar
implementado en el SGBD.

Y el verdadero nivel de DataAccess está resuelto por el DBMS, que es
el que se encarga de acceder a los datos guardados en la memoria y los
discos duros.

al hacer ese mapeo estoy brindando un acceso directo desde la BBDD a la
interfaz del usuario.

No, lo que estás haciendo es enlazando (bindar es espanglis)
directamente la interfaz de usuario con el SGBD, que es lo que hay que
hacer.

Si utilizas un SGBD las aplicaciones quedan automáticamente separadas
de la base de datos. Las aplicaciones nunca deben de tener acceso
directo a la base de datos, sino que deben de comunicarse con un SGBD.

Y también el caso opuesto, los ingresos y modificaciones del usuario que se
insertarían en forma directa en la BBDD.

No, las acciones del usuario se transformarían en ordenes para el
SGBD, y el SGBD procesaría las órdenes.

Eso no contradice presisamente el desarrollo en niveles?

No, lo que contradice el desarrollo en niveles es lo contrario. Lo de
crear aplicaciones monolíticas que se encargen de la presentación, la
lógica de negocio y el acceso a la base de datos. Esto dejó de hacerse
en los años 60, pero nuevas generaciones de programadores poco
preparados han resucitado estas prácticas primitivas. Muchos
programadores no saben lo que es un SGBD realmente y lo utilizan como
si fuese un procesador de ficheros (o mecanismo de persistencia como
le llaman algunos ignorantes), y lo peor es que algunos hasta se
atreven a escribir libros.

Lo de los tres niveles se refiere al sistema, y no a la aplicación.

La aplicación se debe de ocupar solamente de uno de los tres niveles:
el de presentación.

Los tres niveles lógicos de un sistema de información deben de ser los
siguientes:

Aplicación <> SGBD <--> Base de Datos.
(presentacion) (lógica de negocio) (datos)
(interfaz usuario) (persistencia)
(seguridad)
(etc.)

Por supuesto cada nivel se pueden descomponer en varios subniveles.
Por ejemplo existen SGBD distribuidos que se ejecutan en varios
servidores, y SGBD virtuales que sirven de intermediarios entre las
aplicaciones y otros SGBD.

Por otra parte el nivel de aplicación puede tener subniveles como el
de comunicación con el DBMS. Este subnivel normalmente está resuelto
por los fabricantes de herramientas de programación (bibliotecas ODBC,
ADO.NET, etc), por lo que los programadores de aplicaciones
normalmente no tienen que preocuparse de él.


Saludos

Gracias Alfredo por la info.
Me pondré a leer un poco sobre esto.
Yo también estuve haciendo cosas similarmente a como las plantea Carlos al
inicio del hilo.
Y es que obtuve esa info de páginas del mismo MS...
Sin dudas que hay muchas aproximaciones al tema.

Saludos cordiales.

Sergio Cossa
Argentina

"Alfredo Novoa" wrote in message
news:
On Tue, 15 Feb 2005 11:53:06 -0300, "Sergio Cossa"
wrote:

Perdón por mi escaso conocimiento en el tema...

No hay nada que perdonar.

Si yo tengo una aplicación de 3 niveles, DataAccess ( a través de
webservices ), Business y UI ( trabajando en una aplicación de winforms ),

El nombre que se le da a los niveles ya indica que es probable que las
cosas se estén haciendo mal.

Por ejemplo lo de "DataAccess" debería de ser DBMS Access.

Las peticiones que se le hacen al DBMS deberían de ser en el lenguage
del SGBD (SQL normalmente).

El nivel Business, también llamado de lógica de negocio debe de estar
implementado en el SGBD.

Y el verdadero nivel de DataAccess está resuelto por el DBMS, que es
el que se encarga de acceder a los datos guardados en la memoria y los
discos duros.

al hacer ese mapeo estoy brindando un acceso directo desde la BBDD a la
interfaz del usuario.

No, lo que estás haciendo es enlazando (bindar es espanglis)
directamente la interfaz de usuario con el SGBD, que es lo que hay que
hacer.

Si utilizas un SGBD las aplicaciones quedan automáticamente separadas
de la base de datos. Las aplicaciones nunca deben de tener acceso
directo a la base de datos, sino que deben de comunicarse con un SGBD.

Y también el caso opuesto, los ingresos y modificaciones del usuario que se
insertarían en forma directa en la BBDD.

No, las acciones del usuario se transformarían en ordenes para el
SGBD, y el SGBD procesaría las órdenes.

Eso no contradice presisamente el desarrollo en niveles?

No, lo que contradice el desarrollo en niveles es lo contrario. Lo de
crear aplicaciones monolíticas que se encargen de la presentación, la
lógica de negocio y el acceso a la base de datos. Esto dejó de hacerse
en los años 60, pero nuevas generaciones de programadores poco
preparados han resucitado estas prácticas primitivas. Muchos
programadores no saben lo que es un SGBD realmente y lo utilizan como
si fuese un procesador de ficheros (o mecanismo de persistencia como
le llaman algunos ignorantes), y lo peor es que algunos hasta se
atreven a escribir libros.

Lo de los tres niveles se refiere al sistema, y no a la aplicación.

La aplicación se debe de ocupar solamente de uno de los tres niveles:
el de presentación.

Los tres niveles lógicos de un sistema de información deben de ser los
siguientes:

Aplicación <> SGBD <--> Base de Datos.
(presentacion) (lógica de negocio) (datos)
(interfaz usuario) (persistencia)
(seguridad)
(etc.)

Por supuesto cada nivel se pueden descomponer en varios subniveles.
Por ejemplo existen SGBD distribuidos que se ejecutan en varios
servidores, y SGBD virtuales que sirven de intermediarios entre las
aplicaciones y otros SGBD.

Por otra parte el nivel de aplicación puede tener subniveles como el
de comunicación con el DBMS. Este subnivel normalmente está resuelto
por los fabricantes de herramientas de programación (bibliotecas ODBC,
ADO.NET, etc), por lo que los programadores de aplicaciones
normalmente no tienen que preocuparse de él.


Saludos

On Wed, 16 Feb 2005 18:48:54 -0300, "Sergio Cossa"
wrote:

Me pondré a leer un poco sobre esto.

Pues ten cuidado con lo que lees, por que la gran mayoría de lo que
hay tiene muy poca calidad. Especialmente lo que escriben los
fabricantes de Software. Deberías acudir a textos universitarios, y
aun así suelen tener bastantes errores.

Lo mejor que hay en español es:

"Introducción a los Sistemas de Bases de Datos 7ª Edición" de C.J.
Date.

Es uno de los libros de texto universitarios más usados y el mejor con
mucha diferencia explicando el Modelo Relacional, aunque habla muy
poco sobre la implementación de los DBMS.

No conozco ningúna web en español sobre bases de datos que sea
decente, pero en inglés tienes: www.dbdebunk.com

Tiene una sección de libros muy recomendable.

Yo también estuve haciendo cosas similarmente a como las plantea Carlos al
inicio del hilo.
Y es que obtuve esa info de páginas del mismo MS...

Desgraciadamente no es una buena referencia para aprender los
fundamentos teoricos de los sistemas de información.

Las páginas de los fabricantes SOLO deberían usarse para conocer
detalles sobre los productos que venden, y NUNCA para aprender sobre
los fundamentos teóricos de la profesión.

Sin dudas que hay muchas aproximaciones al tema.

Pero solo hay una que es la buena.


Saludos