Cita:
Empezado por roman
Pues algo así. Pero ése es el problema. La VCL implementa este patrón precisamente en la conexión DataSet<--DataSources y DataSource<--DataLinks, así que suena demasiado tener que hacerlo otra vez para sincronizar la interfaz con el acceso a datos. Por ello es que la solución de Al me parece muy adecuada.
|
Por eso mismo mis ideas pasan por emplearlo. Si el patrón Observador me garantiza esa "sincronización" ¿Porqué no usarlo?
Es cierto que aplicarlo tiene sus desventajas... y si no empleamos objetos data-ware... ¡ni que hablar! Que ya he visto varios hilos en donde se expone el tema.
Son distintas soluciones, y alternativas. En fin, me parece que buscarle un solo punto de vista que sea productivo y que nos solucione todos los problemas es algo muy dificil de conseguir.
Cita:
Empezado por roman
Por otra parte;
Yo quisiera que esto no fuera así amigos. Porque aquí hay gente con mucha más experiencia que yo y mi opinión no necesariamente refleja lo más adecuado. Aquí, por ejemplo, yo pregunto, porque me parece raro que la VCL maneje así las cosas siendo que se supone que los datamodules están ahí precisamente para separar la interfaz del acceso de datos. Entonces pienso: quizá yo no estoy entendiendo bien y quiero ver cómo hacen los demás. Pero es eso, una pregunta, y no la verdad de cómo deben hacerse las cosas.
|
Yo no soy quien para decir si lo dicho por ti y otros es lo más adecuado, pero reconozco que tus palabras son a tener en cuenta.
A mi me parece que los motivos de los ingenieros de codegear para estructurar asi la VCL fue certero. Y como toda decisión implica llevar sus pros y contras.
Se separa amigo, y como sabemos... no se puede evitar la relación. Si podemos estructurar el trabajo de tal forma que se reduzca la dependencias y relación entre estas dos capas.
En lo personal, me encantaría decirte que yo trabajo de x forma. Pero como he dicho antes... todavía estoy analizando este tema. Y por el momento, no tengo una inclinación de uno sobre otros. Si puedo decir que se que parte de ello se debe a mi manera casi "purista" de verlo bajo el microscopio de POO. El tener una postura demasiada pura en este asunto me nubla y me impide decir: "Este diseño soluciona todos mis problemas".
La cuestión está en encontrar un punto de vista que nos resulte cómodo. Y para mi, por el momento el punto de vista cómodo pasa por analizar caso por caso (proyecto por proyecto) en vez de imponer un diseño único a todos mis desarrollos (mejor dicho... futuros desarrollos) e ideas.
Esto no quita que tenga en mente la idea de reutilización, y otros conceptos y buenas prácticas. Entre ellas el diseño de bibliotecas de propósito general, alguna especie de "framework", y demás cosas que asisten y facilitan el trabajo.
Lo que digo es que a mi modo de ver, el diseño de la arquitectura prefiero analizarlo desde el punto de vista de los requisitos, restricciones de proyecto, planes a futuro... en definitiva en base al ambiente o negocio.
Si mis análisis me demuestran que el sistema no va a ser demasiado volátil, y no requiere demasiada indepedencia entre las capas (una capa de negocio delgada tal vez) un diseño rápido es lo más útil y puede que tener todo en un datamodule basta y sobre.
Pero si hay probabilidades de que el sistema fluctue, se amplie, se cambien el motor, y el ambiente demuestra una gran complejidad en sus operaciones, prefiero una alternativa dirjida hacia garantizar lo máximo posible la independencia de cada capa. Y esto me llevará a analizar que es mejor:
1. la eterna pregunta ¿usar data-ware?
2. Un diseño asistido por observadores
3. Un diseño orientado como la descripción de roman
4. Un diseño como el que menciona roman, y la alternativa de Al
5. etc...
6. ¿Una mezcla de éstas?
Cita:
Empezado por roman
Espero que no se tomen a mal esto, desde luego que es halagador que la gente piense que la opinión de uno tiene peso, pero el tener muchos posts, no es lo mismo que tener mucha experiencia.
// Saludos
|
Yo no tengo demasiada experiencia. Y por ello mucho no puedo decir.
Saludos,