Factura, líneas de facturas, artículo

Hola Alfredo:

Si bien lo que tu me comentas es correcto en cuanto a bases de datos, mi
inquietud era en cuanto una mayor abstracción de los conceptos Factura.
Si bien es correcto que se pueden almacernar en una base de datos, no menos
cierto es que podría almacenar las facturas en otros medios (XML, etc)

En cuanto a la abstracción, lo que pregunto tiene MUCHO que ver con UML y
POO, es decir, en mi pregunta se centraba en la lógica de la aplicación
dejando de forma secundaria su almacenamiento. Mi pregunta se centraba en el
diseño de la lógica y objetos para solucionar estas cuestiones:

- Si relacionamos una línea de factura y artículo, que pasa si (el
usuario desea borrar un articulo, el usuario modifica el precio, el usuario
modifica la descripción del artículo, etc.). Lo que sucede es que la factura
se modifica, es decir, que si cambiasemos por ejemplo un artículo, por
ejemplo "Lapicero", cambiamos su descripción por "Bolígrafo" y su pecio de 1
euro por dos. Todas aquellas facturas en el sistema que tengan líneas
relacionadas con este artículo se cambiarían, cosa no deseada, porque las
facturas se tienen que mantener invariables.

La solución que ahora pienso diseñar es la siguiente, haber que les parece:

- Crear una clase Artículo con su código, precio, descripción, etc.
- Crear una clase llamada ArticuloLínea que heredará toda la funcionalidad
de Artículo. Lo que variará de Articulo es su lógica de almacenamiento de
sus datos para almacenar estos en otra tabla o donde sea.
-Crear una clase Línea que asociaremos a ArtículoLínea. Ahora al asociar un
artículo a la línea, copiaremos toda su información al artículolínea
relacionado con la línea, así cualquier modificación en el Artículo no
afectará a la información de la línea.

- Lo mismo podría realizarse con la relación de la clase Cliente con la
clase factura. Podríamos crear la clase ClienteFactura y copiar aquí la
información de cliente y relacionar esta clase con la factura. Así futuras
modificaciones del cliente no afectarian a la información de la cabecera de
la factura.

¿Que les parece ?

Gracias de antemano por su tiempo
Bix


"Alfredo Novoa" escribió en el mensaje
news:

Hola,

On Fri, 17 Nov 2006 16:03:07 +0100, "Bingen"
wrote:

Hola a todos:

Mi pregunta es la siguiente, la verdad que podría colgarse en cualquier
otro
lenguaje pero...

tenemos una clase Factura que agrupa líneas de factura. Estas líneas de
factura tienen una cantidad y una relación con un artículo.

No veo que puede aportar tener una clase como esa.

Mi duda es la siguiente, si la línea la relacionamos con un artículo (nos
da
la información de descripción de artículo, código artículo precio), es
decir
tenemos una propiedad en la clase línea que es un objeto artículo, nuestro
sistema está obligado a no dejarnos borrar artículos ¿verdad?, porque si
no,
todas las líneas de facturas que contengan dicho articulo, quedan inutiles
¿
no?.

¿ Que filosofia empleais vosotros ?

Usar un SGBD para gestionar los datos y no hacerlo desde la aplicación
con código procedimental.

Para que no te deje borrar los artículos se crea una "Foreign Key" y
listo. Implementar esto mediante código de la aplicación es un
disparate.

otra cosa, algún sitio de discusiones de UML (o preguntas similiares...)

Lo que preguntas no tiene nada que ver con UML ni con la OO. No debes
de usar la OO para gestionar datos. La OO no sirve para eso.


Saludos
Alfredo

Hola,

On Mon, 20 Nov 2006 17:08:01 +0100, "Bingen"
wrote:

Si bien lo que tu me comentas es correcto en cuanto a bases de datos, mi
inquietud era en cuanto una mayor abstracción de los conceptos Factura.

SQL es un lenguaje con mucho mayor nivel de abstracción que C#.

Intentar abstraer una tabla SQL con construcciones C# tiene aun menos
sentido que intentar abstraer código C# usando ensamblador.

Si bien es correcto que se pueden almacernar en una base de datos, no menos
cierto es que podría almacenar las facturas en otros medios (XML, etc)

Una base de datos es un conjunto de datos independientemente de como
se gestione. Si tienes una base de datos guardada en un archivo XML
sigue siendo una base de datos.

Crear un sistema de información mínimamente complejo sin utilizar un
SGBD es un disparate.

En cuanto a la abstracción, lo que pregunto tiene MUCHO que ver con UML y
POO, es decir, en mi pregunta se centraba en la lógica de la aplicación

Tu pregunta se centraba sobre la lógica de datos. En un sistema de
información la lógica de aplicaciones debe de ser solamente la lógica
de presentación y comunicación. La suma de todos estos tipos de lógica
forma la lógica del sistema (de información).

dejando de forma secundaria su almacenamiento.

El almacenamiento no tiene nada que ver con la lógica de datos.

Mi pregunta se centraba en el
diseño de la lógica y objetos para solucionar estas cuestiones:

- Si relacionamos una línea de factura y artículo, que pasa si (el
usuario desea borrar un articulo, el usuario modifica el precio, el usuario
modifica la descripción del artículo, etc.). Lo que sucede es que la factura
se modifica, es decir, que si cambiasemos por ejemplo un artículo, por
ejemplo "Lapicero", cambiamos su descripción por "Bolígrafo" y su pecio de 1
euro por dos. Todas aquellas facturas en el sistema que tengan líneas
relacionadas con este artículo se cambiarían, cosa no deseada, porque las
facturas se tienen que mantener invariables.

Esto es sin ningunar duda lógica de base de datos, por lo tanto debe
de quedar fuera de las aplicaciones.

Todo esto es trivial si usas un SGBD.

La solución que ahora pienso diseñar es la siguiente, haber que les parece:

- Crear una clase Artículo con su código, precio, descripción, etc.
- Crear una clase llamada ArticuloLínea que heredará toda la funcionalidad
de Artículo. Lo que variará de Articulo es su lógica de almacenamiento de
sus datos para almacenar estos en otra tabla o donde sea.
-Crear una clase Línea que asociaremos a ArtículoLínea. Ahora al asociar un
artículo a la línea, copiaremos toda su información al artículolínea
relacionado con la línea, así cualquier modificación en el Artículo no
afectará a la información de la línea.

- Lo mismo podría realizarse con la relación de la clase Cliente con la
clase factura. Podríamos crear la clase ClienteFactura y copiar aquí la
información de cliente y relacionar esta clase con la factura. Así futuras
modificaciones del cliente no afectarian a la información de la cabecera de
la factura.

¿Que les parece ?

Que viola casi todos los principios de diseño de sistemas de
información.


Saludos
Alfredo

Hola Alfredo:

SQL es un lenguaje con mucho mayor nivel de abstracción que C#.

Te suena la herencia y el polimorfismo, etc... Qué nivel de abstracción
tiene una tabla de cliente (campos de tipos de la base de datos) respecto a
una clase de cliente en la que englobamos en ella podemos englobar
información de tipos dispares (hasta propios)

Intentar abstraer una tabla SQL con construcciones C# tiene aun menos
sentido que intentar abstraer código C# usando ensamblador.

Yo parto de la manera inversa, primeramente se estudia el problema (modelo
conceptual, de diseño, etc) y luego determinamos que clases deben ser
persistentes, en una BD, etc..

Crear un sistema de información mínimamente complejo sin utilizar un
SGBD es un disparate.

¿ Quien a dicho lo contrario ?

Tu pregunta se centraba sobre la lógica de datos. En un sistema de
información la lógica de aplicaciones debe de ser solamente la lógica
de presentación y comunicación. La suma de todos estos tipos de lógica
forma la lógica del sistema (de información).

Podría existir una capa de lógica de presentación, una de lógica de
negocio, una de persistencia de datos, otra de datos (un proveedor de bd,
ficheros planos, XML, etc)

Mi pregunta se centraba en el
diseño de la lógica y objetos para solucionar estas cuestiones:

- Si relacionamos una línea de factura y artículo, que pasa si (el
usuario desea borrar un articulo, el usuario modifica el precio, el
usuario
modifica la descripción del artículo, etc.). Lo que sucede es que la
factura
se modifica, es decir, que si cambiasemos por ejemplo un artículo, por
ejemplo "Lapicero", cambiamos su descripción por "Bolígrafo" y su pecio de
1
euro por dos. Todas aquellas facturas en el sistema que tengan líneas
relacionadas con este artículo se cambiarían, cosa no deseada, porque las
facturas se tienen que mantener invariables.

Esto es sin ningunar duda lógica de base de datos, por lo tanto debe
de quedar fuera de las aplicaciones.

Todo esto es trivial si usas un SGBD.

¿ Si ?, eso quiero, respuestas, porque por eso pido vuestra opinión, pero
Alfredo, seamos más explicitos.

La solución que ahora pienso diseñar es la siguiente, haber que les
parece:

- Crear una clase Artículo con su código, precio, descripción, etc.
- Crear una clase llamada ArticuloLínea que heredará toda la funcionalidad
de Artículo. Lo que variará de Articulo es su lógica de almacenamiento de
sus datos para almacenar estos en otra tabla o donde sea.
-Crear una clase Línea que asociaremos a ArtículoLínea. Ahora al asociar
un
artículo a la línea, copiaremos toda su información al artículolínea
relacionado con la línea, así cualquier modificación en el Artículo no
afectará a la información de la línea.

- Lo mismo podría realizarse con la relación de la clase Cliente con la
clase factura. Podríamos crear la clase ClienteFactura y copiar aquí la
información de cliente y relacionar esta clase con la factura. Así futuras
modificaciones del cliente no afectarian a la información de la cabecera
de
la factura.

¿Que les parece ?

Que viola casi todos los principios de diseño de sistemas de
información.

¿ Esta mal ?, Semos más explicitos.

Un saludo y gracias por tu tiempo
Bix




"Alfredo Novoa" escribió en el mensaje
news:

Hola,

On Mon, 20 Nov 2006 17:08:01 +0100, "Bingen"
wrote:

Si bien lo que tu me comentas es correcto en cuanto a bases de datos, mi
inquietud era en cuanto una mayor abstracción de los conceptos Factura.

SQL es un lenguaje con mucho mayor nivel de abstracción que C#.

Intentar abstraer una tabla SQL con construcciones C# tiene aun menos
sentido que intentar abstraer código C# usando ensamblador.

Si bien es correcto que se pueden almacernar en una base de datos, no
menos
cierto es que podría almacenar las facturas en otros medios (XML, etc)

Una base de datos es un conjunto de datos independientemente de como
se gestione. Si tienes una base de datos guardada en un archivo XML
sigue siendo una base de datos.

Crear un sistema de información mínimamente complejo sin utilizar un
SGBD es un disparate.

En cuanto a la abstracción, lo que pregunto tiene MUCHO que ver con UML y
POO, es decir, en mi pregunta se centraba en la lógica de la aplicación

Tu pregunta se centraba sobre la lógica de datos. En un sistema de
información la lógica de aplicaciones debe de ser solamente la lógica
de presentación y comunicación. La suma de todos estos tipos de lógica
forma la lógica del sistema (de información).

dejando de forma secundaria su almacenamiento.

El almacenamiento no tiene nada que ver con la lógica de datos.

Mi pregunta se centraba en el
diseño de la lógica y objetos para solucionar estas cuestiones:

- Si relacionamos una línea de factura y artículo, que pasa si (el
usuario desea borrar un articulo, el usuario modifica el precio, el
usuario
modifica la descripción del artículo, etc.). Lo que sucede es que la
factura
se modifica, es decir, que si cambiasemos por ejemplo un artículo, por
ejemplo "Lapicero", cambiamos su descripción por "Bolígrafo" y su pecio de
1
euro por dos. Todas aquellas facturas en el sistema que tengan líneas
relacionadas con este artículo se cambiarían, cosa no deseada, porque las
facturas se tienen que mantener invariables.

Esto es sin ningunar duda lógica de base de datos, por lo tanto debe
de quedar fuera de las aplicaciones.

Todo esto es trivial si usas un SGBD.

La solución que ahora pienso diseñar es la siguiente, haber que les
parece:

- Crear una clase Artículo con su código, precio, descripción, etc.
- Crear una clase llamada ArticuloLínea que heredará toda la funcionalidad
de Artículo. Lo que variará de Articulo es su lógica de almacenamiento de
sus datos para almacenar estos en otra tabla o donde sea.
-Crear una clase Línea que asociaremos a ArtículoLínea. Ahora al asociar
un
artículo a la línea, copiaremos toda su información al artículolínea
relacionado con la línea, así cualquier modificación en el Artículo no
afectará a la información de la línea.

- Lo mismo podría realizarse con la relación de la clase Cliente con la
clase factura. Podríamos crear la clase ClienteFactura y copiar aquí la
información de cliente y relacionar esta clase con la factura. Así futuras
modificaciones del cliente no afectarian a la información de la cabecera
de
la factura.

¿Que les parece ?

Que viola casi todos los principios de diseño de sistemas de
información.


Saludos
Alfredo

On Tue, 21 Nov 2006 08:46:13 +0100, "Bingen"
wrote:

SQL es un lenguaje con mucho mayor nivel de abstracción que C#.

Te suena la herencia y el polimorfismo, etc...

Pequeñeces comparado con el nivel de abstracción de la programación
declarativa.

Qué nivel de abstracción
tiene una tabla de cliente (campos de tipos de la base de datos) respecto a
una clase de cliente en la que englobamos en ella podemos englobar
información de tipos dispares (hasta propios)

Te veo bastante verde en teoría de bases de datos. Te recomiendo un
excelente libro:

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

Yo parto de la manera inversa, primeramente se estudia el problema (modelo
conceptual, de diseño, etc) y luego determinamos que clases deben ser
persistentes, en una BD, etc..

Un enfoque equivocado.

Primero deberías de crear un diseño conceptual de la base de datos,
luego un diseño lógico y luego un diseño físico. Después de esto
puedes empezar a diseñar las aplicaciones. Aunque el diseño físico de
la base de datos si quieres lo puedes dejar para el final, lo otro no.

Crear un sistema de información mínimamente complejo sin utilizar un
SGBD es un disparate.

¿ Quien a dicho lo contrario ?

Tu has sugerido que se podría usar un archivo XML el lugar de un SGBD
y no es una opción sensata.

Podría existir una capa de lógica de presentación, una de lógica de
negocio, una de persistencia de datos, otra de datos (un proveedor de bd,
ficheros planos, XML, etc)

Aquí vuelves a sugerir que podríamos no usar un SGBD.

La capa de lógica de negocio debe de implementarse en el SGBD con
tablas, vistas, restricciones, procedimientos almacenados, etc, y
nunca en las aplicaciones. De la persistencia ya se encarga el SGBD
sin que los programadores tengan que hacer nada. En todo caso los
detalles sobre la persistencia son cosa del DBA.

Todo esto es trivial si usas un SGBD.

¿ Si ?, eso quiero, respuestas, porque por eso pido vuestra opinión, pero
Alfredo, seamos más explicitos.

Si lees el libro que te recomendé lo verás claro. Creo que ya he sido
bastante explícito: la lógica de negocio debe de asegurarla el SGBD y
no las aplicaciones. Para eso tienes tablas, vistas, vistas indexadas,
constraints, procedimientos almacenados, tipos definidos por el
usuario, etc. Los procedimientos deben de ser el último recurso.

Un sistema de información no son solo las aplicaciones, y un SGBD es
muchísimo más que un gestor de persistencia.


Saludos

Bingen:

Creo que la discusión nació interesante pero se ha desvirtuado por las
controversias.

No estoy de acuerdo con Alfredo en cuanto a que tener una clase de ese tipo
no aporta nada. Pero creo que tú creas la confusión al hablar de las
restricciones (no poder borrar un artículo que está referenciado en una
factura, por ejemplo) cuando estás hablando de la clase.

Mi opinión es que únicamente el SGBD debe encargarse de administrar la
integridad de los datos y las clases serían buenas herramientas para
trabajar con esos datos.

¡Saludos!

*****************************************************
Daniel Ruzo
Miembro del GCU (Grupo Clarion Uruguay)
*****************************************************
"Bingen" escribió en el mensaje
news:eJpJ%

Hola Alfredo:

SQL es un lenguaje con mucho mayor nivel de abstracción que C#.

Te suena la herencia y el polimorfismo, etc... Qué nivel de abstracción
tiene una tabla de cliente (campos de tipos de la base de datos) respecto
a una clase de cliente en la que englobamos en ella podemos englobar
información de tipos dispares (hasta propios)

Intentar abstraer una tabla SQL con construcciones C# tiene aun menos
sentido que intentar abstraer código C# usando ensamblador.

Yo parto de la manera inversa, primeramente se estudia el problema (modelo
conceptual, de diseño, etc) y luego determinamos que clases deben ser
persistentes, en una BD, etc..

Crear un sistema de información mínimamente complejo sin utilizar un
SGBD es un disparate.

¿ Quien a dicho lo contrario ?

Tu pregunta se centraba sobre la lógica de datos. En un sistema de
información la lógica de aplicaciones debe de ser solamente la lógica
de presentación y comunicación. La suma de todos estos tipos de lógica
forma la lógica del sistema (de información).

Podría existir una capa de lógica de presentación, una de lógica de
negocio, una de persistencia de datos, otra de datos (un proveedor de bd,
ficheros planos, XML, etc)

Mi pregunta se centraba en el
diseño de la lógica y objetos para solucionar estas cuestiones:

- Si relacionamos una línea de factura y artículo, que pasa si (el
usuario desea borrar un articulo, el usuario modifica el precio, el
usuario
modifica la descripción del artículo, etc.). Lo que sucede es que la
factura
se modifica, es decir, que si cambiasemos por ejemplo un artículo, por
ejemplo "Lapicero", cambiamos su descripción por "Bolígrafo" y su pecio
de 1
euro por dos. Todas aquellas facturas en el sistema que tengan líneas
relacionadas con este artículo se cambiarían, cosa no deseada, porque las
facturas se tienen que mantener invariables.

Esto es sin ningunar duda lógica de base de datos, por lo tanto debe
de quedar fuera de las aplicaciones.

Todo esto es trivial si usas un SGBD.

¿ Si ?, eso quiero, respuestas, porque por eso pido vuestra opinión, pero
Alfredo, seamos más explicitos.

La solución que ahora pienso diseñar es la siguiente, haber que les
parece:

- Crear una clase Artículo con su código, precio, descripción, etc.
- Crear una clase llamada ArticuloLínea que heredará toda la
funcionalidad
de Artículo. Lo que variará de Articulo es su lógica de almacenamiento de
sus datos para almacenar estos en otra tabla o donde sea.
-Crear una clase Línea que asociaremos a ArtículoLínea. Ahora al asociar
un
artículo a la línea, copiaremos toda su información al artículolínea
relacionado con la línea, así cualquier modificación en el Artículo no
afectará a la información de la línea.

- Lo mismo podría realizarse con la relación de la clase Cliente con la
clase factura. Podríamos crear la clase ClienteFactura y copiar aquí la
información de cliente y relacionar esta clase con la factura. Así
futuras
modificaciones del cliente no afectarian a la información de la cabecera
de
la factura.

¿Que les parece ?

Que viola casi todos los principios de diseño de sistemas de
información.

¿ Esta mal ?, Semos más explicitos.

Un saludo y gracias por tu tiempo
Bix




"Alfredo Novoa" escribió en el mensaje
news:

Hola,

On Mon, 20 Nov 2006 17:08:01 +0100, "Bingen"
wrote:

Si bien lo que tu me comentas es correcto en cuanto a bases de datos, mi
inquietud era en cuanto una mayor abstracción de los conceptos Factura.

SQL es un lenguaje con mucho mayor nivel de abstracción que C#.

Intentar abstraer una tabla SQL con construcciones C# tiene aun menos
sentido que intentar abstraer código C# usando ensamblador.

Si bien es correcto que se pueden almacernar en una base de datos, no
menos
cierto es que podría almacenar las facturas en otros medios (XML, etc)

Una base de datos es un conjunto de datos independientemente de como
se gestione. Si tienes una base de datos guardada en un archivo XML
sigue siendo una base de datos.

Crear un sistema de información mínimamente complejo sin utilizar un
SGBD es un disparate.

En cuanto a la abstracción, lo que pregunto tiene MUCHO que ver con UML y
POO, es decir, en mi pregunta se centraba en la lógica de la aplicación

Tu pregunta se centraba sobre la lógica de datos. En un sistema de
información la lógica de aplicaciones debe de ser solamente la lógica
de presentación y comunicación. La suma de todos estos tipos de lógica
forma la lógica del sistema (de información).

dejando de forma secundaria su almacenamiento.

El almacenamiento no tiene nada que ver con la lógica de datos.

Mi pregunta se centraba en el
diseño de la lógica y objetos para solucionar estas cuestiones:

- Si relacionamos una línea de factura y artículo, que pasa si (el
usuario desea borrar un articulo, el usuario modifica el precio, el
usuario
modifica la descripción del artículo, etc.). Lo que sucede es que la
factura
se modifica, es decir, que si cambiasemos por ejemplo un artículo, por
ejemplo "Lapicero", cambiamos su descripción por "Bolígrafo" y su pecio
de 1
euro por dos. Todas aquellas facturas en el sistema que tengan líneas
relacionadas con este artículo se cambiarían, cosa no deseada, porque las
facturas se tienen que mantener invariables.

Esto es sin ningunar duda lógica de base de datos, por lo tanto debe
de quedar fuera de las aplicaciones.

Todo esto es trivial si usas un SGBD.

La solución que ahora pienso diseñar es la siguiente, haber que les
parece:

- Crear una clase Artículo con su código, precio, descripción, etc.
- Crear una clase llamada ArticuloLínea que heredará toda la
funcionalidad
de Artículo. Lo que variará de Articulo es su lógica de almacenamiento de
sus datos para almacenar estos en otra tabla o donde sea.
-Crear una clase Línea que asociaremos a ArtículoLínea. Ahora al asociar
un
artículo a la línea, copiaremos toda su información al artículolínea
relacionado con la línea, así cualquier modificación en el Artículo no
afectará a la información de la línea.

- Lo mismo podría realizarse con la relación de la clase Cliente con la
clase factura. Podríamos crear la clase ClienteFactura y copiar aquí la
información de cliente y relacionar esta clase con la factura. Así
futuras
modificaciones del cliente no afectarian a la información de la cabecera
de
la factura.

¿Que les parece ?

Que viola casi todos los principios de diseño de sistemas de
información.


Saludos
Alfredo