FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
|||
|
|||
Arquitectura en código de un sistema de BD
La verdad es que se comenta mucho de como hacer esto lo otro, pero no he podido tener la oportunidad, de consultar con otras personas: cuál es el procedimiento a seguir desde el punto de vista arquitectonico para diseñar sistemas de base de datos, es decir cuantas unit debe tener la aplicación según el análisis y diseño realizado anteriormente y en cual introdusco esta clase o la otra, aunque tengo mi propio estilo para el diseño, pienso que debe existir una manera estandar de hacer las cosas principalmente para los sistemas de Base de Datos que claro en delphi manipula muy bien sobre todo con los controles Dataware, mi pregunta es la siguiente ¿Puedo utilizar estos controles en un sistema diseñando OO? si lo puedo utilizar ¿Como es que lo utilizo en las clases si existe una relación de modelo de tres capas ?
Espero que entiendan mis ideas y que me ayuden a aclarar el tema. |
#2
|
||||
|
||||
A ver: Object Pascal tiene soporte OO nativo, ¿no? Entonces, ¿por qué dudas de que pueda hacerse?
|
#3
|
|||||||
|
|||||||
Hola FaraonDX, bienvenido a clubdelphi.
No se si estoy entendiendo bien tu pregunta. Tu dirás si me equivoco. Cita:
POr más empleo de métricas, y buenas prácticas que uses para determinar tanto el acomplamiento y cohesión que hay presente entre los módulos (y en el módulo). Hay un factor subjetivo que afecta (en mi experiencia) en forma proporcional a la complejidad del sistema. Una primera aproximación para determinar la cantidad de unidades puede ser esta: Cita:
Cita:
Cita:
No se como debería interpretar la parte de modelo de tres capas. He visto muchas definiciones de lo esto significa. En lo personal, tres capas significa para mi esto: ------------- Capa Interfaz -> Entrada y Salida de datos. ------------- Capa Lógica -> Clases, y/o funciones o procedimientos que operan sobre los datos ingresados y/o recuperados de la base datos (para luego mostrarlos) ------------- Capa Datos -> Módulo de datos (DataModule), Base de datos. ------------- Si es que lo que entiendo por tres capas es correcto, y viendo lo que comentas sobre dataware, estos están en la capa de Interfaz, ya que se adosan a esta última. Ten en cuenta que estos componentes responderán a las fuentes de Datos (DataSource, etc). Ahora, veo que parece que estás siguiendo un enfoque OO (Sería lógico. ya que es un punto fuerte que ofrece Delphi). Por un lado tienes las units que responden a tu interfaz y por el otro las que tienen definida toda tu estructura (diagrama de clases) con sus jerarquías, relaciones, etc... Y por el otro las más bajas: la de datos. La pregunta a la respuesta ¿Cuantas unit son necesarias? Debe responder a estos 3 tipos de units. Como dije antes: Cita:
La cantidad de units responderá en sintesis a una compensación y equilibrio entre tus tres capas. Me encantaría seguir comentando sobre lo referente a la capa lógica. Pero esto sería oportuno dedicarlo y tratarlo en un hilo aparte. Como recomendación, deberás tener en cuenta que la cantidad de unidades lógicas a contar responderá también a esta pregunta: Cita:
Veamos con un ejemplo: tienes 15 clases, por comodidad cada una declarada en una unidad diferente. De estas 15, 5 son desdendientes. Estas 15 clases fueron definidas en un momento anterior y son para propósito general. Te da un sistema para hacer y notas que puedes reutilizar la clase inferior que mantienen una relación de herencia (las 5). La pregunta es: ¿Incluirías a la cuenta, las 5 de propósito general , las 15 en su totalidad, o sólo la que empleas para heredar y trabajar? Lo que trato de decirte es que deberás saber donde termina y comienza tu sistema. Seguir un modelo OO tiene sus claras ventajas pero al momento de la reutilización de módulos y unidades se hace confuso hacer una estimación para llevar el análisis y diseño de tu sistema. En síntesis. Deberás responderte. Cita:
Espero haberte sido de ayuda. Y si entendí mal, mil disculpas. |
#4
|
|||
|
|||
construyendo piramides
Me alegra mucho que hallas, respondido a mis interrogantes, he visto algunos comentarios tuyos en diferentes temas y estoy de acuerdo en casi todos. En realidad tambien pienso que antes de escribir una linea de código hay que tener claro la idea esacta de como quedará el sistema, proyectando una arquitectura en la cual se apliquen los diferentes patrones de diseño, es presisamente esto lo que nos permite tener una mayor reusablidad del código y un facil mantenimiento del sistema. De todas formas todavia me queda la duda de los controles dataware, comentaba anteriormente sobre el modelo de tres capas los controles dataware a mi juicio pertenecen a la capa de interfaz, estos a la hora de implementar un sistema se relacionan con el datasource que pertenece a la capa lógica y los componentes dataset(adotable) pertenece a la capa de datos, por la relación anterior es que me imagino, "a lo mejor estoy equibocado" despues de un diseño OO no podría o mejor dicho no me sería factible utilizar este tipo de relación entre componentes, ya que los objetos que diseño son los que deben estar en relación con los elementos de la interfaz de usuario. Gracias por acudir a mis interrogantes espero que sigas comentando sobre este tema. |
#5
|
||||
|
||||
¿Es esto a lo que te refieres?
Hola de nuevo faraonDX.
Cita:
Cita:
Cita:
¿A que haces referencia cuando dices en relacion con los elementos de la intefaz de usuario? Por lo que logro entender (corrije por favor si me equivoco), tu tienes un diseño basado en OO. Bien perfecto. Creo que tu problema radica en como hacer comunicar tu capa lógica con tu capa de interfaz. Y por la forma en que vienes redactando tu problema es que empleas elementos dataware y estos se comunican derechito con la capa lógica (datasource). Ve al diseño de la capa pero con zonas: ---------------------------------------------------------------------- Capa Interfaz: Zona 1: controles simples - Zona 2: controles dataware ---------------------------------------------------------------------- Capa Lógica: Zona 1: Tu diseño lógico: Clases - Zona 2: Datasource ---------------------------------------------------------------------- Capa Datos: Zona 1: Datamodule, xxDataBase, Table, etc... ---------------------------------------------------------------------- Es decir, Se tiene dos canales de trabajo, por un lado el conformado por el repertorio de controles aportados por delphi (dataware, datasource, etc) lo que conforma un diseño en tres capas. Y en forma paralela tu diseño. Ahora que lo veo, posiblemente Table, Query pertenezcan a la capa lógica. Habría que ver que opinan el resto. Bueno, en fin el resultado será el mismo. Para hacer comunicar tus objetos con la interfaz (independiente del control que sea) se emplean los eventos necesarios que deban dispararse... y pasar el valor de los datos:
Y esta filosofía es la que permite que se envién y pasen los mensajes entre tus objetos y después envien los datos hacia el receptor correspondiente. Por ejemplo puedes aprovechar alimentar a tu objeto cuando los datos han cambiado (on Change de un Data Source). El momento indicado de cuando pasar los datos a tus objetos dependerá del diseño de tus diagramas de secuencia (son fabulosos para ver estas cosas) y otros diagramas que UML nos ofrece. El ejemplo es muy simple... No tengo un ejemplo preparado (código) para que te ilustre mejor la idea. He visto unos ejemplos de BD y POO en varias ocasiones en estos foros. Busca con esos términos. Te puedo recomendar que leas UML y patrones. de Craig Larman, si es que no lo haz leído todavía. Creo que los maestros te pueden dar una mejor perspectiva del asunto. No se si termino de explicarte, y de explicarme. Lo más probable es que haya quedado tinta en el tintero por mi parte. Saludos, |
#6
|
||||
|
||||
Hola delphius, permiteme decirte que me estás aportando ideas, y te lo agradesco mucho, de todas formas voy a tratar de cambiar la tónica y basarme un poco en ejemplos prácticos:
se desea hacer un sistema para controlar datos en una agencia, de los autos se tiene (ID, modelo , marca). Según los que veo en este ejemplo hay dos clases que están presentes: TAgencia y TAuto, y la relación que existe entre ellas es la agregación. Ahora bien en un proyecto en delphi debo utlizar otros elemetos que me aporta el mismo, como el datamodule en el cual se insertan: Conexion,Query, Table , (datasourse). Por lo menos el datamodule genera una clase en una Unit en la que se pueden implementar diferentes métodos. La realidad a mi modo de ver es, que para este problema si yo quiciera desarrollarlo rápido ignoraría las clases TAgencia y TAuto y realizaría la relación (Dataware - DataSource - Table) y ya resuelvo el problema, pero si he realizado un diseño OO entonces necesito que los controles Dataware hagan uso de los métodos de TAuto (por ejemplo) y A la vez TAuto haga uso de DataModule , que pinta entonces el Datasource. Puedes ver un ejemplo sencillo y quizas me entiendas un mejor si visitas el articulo que se encuentra: http://www.rinconcitodelphi.com/arti...PenDelphi1.pdf Espero que entiendas este problema y que aclare las preguntas que me hiciste como: Cita:
Cita:
Cita:
y me puedas argumentar un poco ¿Como ese problema se ve involucrado en:? Cita:
Disculpa si estoy pidiendo mucho. Gracias. |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Sistema TPV con codigo abierto, si es posible | Rabata | Varios | 1 | 01-02-2006 14:06:08 |
Arquitectura de un soft con BD | adlfv | Conexión con bases de datos | 1 | 19-05-2005 18:52:07 |
Desplegar por código el menú de sistema de una ventana | Jan_polero | API de Windows | 7 | 06-05-2005 12:35:25 |
Sun confirma el proyecto de sistema operativo de código abierto 'OpenSolaris' | marcoszorrilla | Noticias | 0 | 25-01-2005 22:04:10 |
Sobre Arquitectura De Bd | ghost | Firebird e Interbase | 0 | 13-10-2004 01:16:51 |
|