![]() |
![]() |
| Paypal | FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
|
|
#1
|
||||
|
||||
|
Hola
Pregunto: Que base de datos usas?. Saludos |
|
#2
|
||||
|
||||
|
estoy usando access
|
|
#3
|
||||
|
||||
|
Hola
En esta pagina del wiki hay varios ejemplos de como hacer la conexion, este en especial es muy básico. Saludos |
|
#4
|
||||
|
||||
|
Cita:
Por otra parte; Cita:
Cita:
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 |
|
#5
|
||||
|
||||
|
Cita:
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:
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:
Saludos, |
|
#6
|
||||
|
||||
|
gracias de todas ya resolvi el problemita solo tenia que inicializar el datamodule primero
|
|
#7
|
||||
|
||||
|
Hola a todos y perdón por revivir este hilo.
Hasta hoy me entero de esta interesante discusión. Comparto lo dicho por Román en mensajes anteriores. Fueron esas inquietudes que plantea las que me llevaron a crear un derivado de TDataSource que tuviera los mismos eventos que las tablas y consultas. Así coloco éstas últimas en los módulos de datos, como tradicionalmente se hace, pero es en los formularios donde pongo los DataSources. De esta manera puedo usar la variedad de eventos de los conjuntos de datos, pero bajo el ámbito de los formularios, quedando todo el código fuente que tiene que ver con el formulario en la unidad .pas del mismo (y no una parte en la unidad .pas del módulo de datos). Logrando que mis formularios sean ahora más independientes y transportables. Cheché puede trabajar con el módulo de datos sin preocuparme de que vaya a tocar algo de código referente al formulario con el que estoy trabajando yo, porque sencillamente ¡TODO el código concerniente al formulario está en la unidad del formulario! (como cualquier programador experimentado que comenzara con Delphi seguramente esperaría). Con esto además evitamos "ensuciar" el módulo de datos (que es una entidad no visual y general para toda la aplicación) con instrucciones de programa que tienen que ver elementos visuales de formularios específicos. Cumpliendo así una regla que nos hemos impuesto en los desarrollos: un módulo de datos no debe "conocer" a la interfaz de usuario, para ser totalmente aprovechable por parte de todas las secciones del programa que lleguen a requerirlo. La capa de arriba conoce a la de abajo, pero no al revés. La capa de abajo queda abiertamente limpia a lo que sea que esté arriba. Esta característica y la capacidad de hacer un clon privado de la propiedad DataSet, son dos cosas que me ayudaron a resolver algunas de las principales vicisitudes de la interacción módulos de datos - formularios. Un saludo. Al González. ![]() |
|
#8
|
|||
|
|||
|
Cita:
además un claro ejemplo de lo que comentas soy yo mismo, muchos post, poca experiancia, eso si, que divertidas me doy por aqui ![]() ![]() ![]() Salud OS
__________________
"La forma de empezar es dejar de hablar y empezar a hacerlo." - Walt Disney |
![]() |
| Herramientas | Buscar en Tema |
| Desplegado | |
|
|
Temas Similares
|
||||
| Tema | Autor | Foro | Respuestas | Último mensaje |
| Remote DataModule | rodalvi | Providers | 0 | 16-05-2007 09:29:51 |
| Error en DataModule | MasterXP | OOP | 2 | 05-10-2005 03:37:35 |
| Datamodule | VRO | Firebird e Interbase | 2 | 13-07-2004 19:00:45 |
| Dudas con el DataModule | ramonibk | Conexión con bases de datos | 3 | 09-07-2004 12:48:15 |
| datamodule | maruenda | Varios | 1 | 31-12-2003 18:24:21 |
|