FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
||||
|
||||
Cita:
La gracia y una de las ventajas que tiene Delphi es justamente el RAD. Y que con pocos pasos ya tienes un ABM funcional. Descartarlo por descartarlo no me parece bueno. Lo que me parece espectacular es que los Ingenieros detrás de Delphi han tenido una muy buena visión de como hacer las cosas y no te condicionan ni te imponen a que para llegar a la bases de datos obligadamente pases por el data-ware. El que sea opcional, y uno considere o no usarlos. No se si otros lenguajes permitirán estas libertades. Si hay algo que siempre han hecho bien el equipo es ofrecer un equilibrio en su VCL. Mi motivo por el cual renuncio al data-ware es más bien centrado a mi visión con tendencia al OO-puro o purismo-OO. En ciertos puntos, si uno se pone a analizarlo se encuentra en el dilema de si usar o no data-ware. Rolphy Reyes y yo en DA hemos intercambiado nuestras experiencias y coincidimos en algunos temas. Ambos nos seguimos cuestionando hasta donde nos puede llegar a facilitar el uso de data-ware y en que punto nos perjudica cuando tenemos presente una capa de de Modelo de Negocio, junto a una Capa de Presentación y otra Capa de Aplicación... y ni que decir, si hemos llegado a pensar en elaborar un Framework de Persistencia. Y creo que acá en CD también se ha debatido este tópico. Es una visión personal. Hay gente a la que el manejo de data-ware les es esencial y a otros que no. No creo que se llegue a una respuesta definitiva que nos diga que deba ganar una cosa por sobre la otra. Después de todo, sea cual fuese el camino que elijas tendrás tus pros y contras. Mientras uno esté al tanto de ambos y encuentre "equilibrio" en sus propios diseños las cosas pueden ser llevadas con normalidad y debido control. Saludos, |
#2
|
||||
|
||||
Cita:
Hola a todos Soy de la misma opinion el usar o no controles dataware no tiene que ser mejor o peor para todos los casos. Yo tengo un sistema funcionando con dataware en una de sus ventanas muestro en un dbgrid la lista de prestamos de mercaderia hechos a un cliente y hay un campo que es el unico editable que es la fecha de devolucion. En este caso se me hace un poco tonto crear un cuadro de dialogo para modificar una sola columna (Si fueran mas se justificaria). Me basto insertar un TDateedit (JVCL) en la columna del grid y listo. Lo que quiero decir es que cada situacion se puede resolver de una u otra forma. Ahora que he cambiado a codetyphon estoy cambiando a un modelo de objetos pero unicamente porque no encuentro un componente que pueda igualar al clientdataset. Saludos
__________________
Caminante, son tus huellas el camino y nada más; Caminante, no hay camino, se hace camino al andar. Antonio Machado |
#3
|
||||
|
||||
Casi que estamos de acuerdo; yo tambien prefiero el modelo purista de objetos porque se permite enchufar a cualquier cosa y no depende de los data-aware. Como migras el mismo codigo a firemonkey para multi plataforma? no podes, no tenes data-aware ahi
Por otra parte, la Starter si tiene los controles data-aware, y tambien tiene ClientDataSet: Y tambien tiene LiveBindings aunque sin el "experto" o plugin del IDE que hace todo mas facil, hay que crear los Binding a mano usando un componente TBindingList y su menu contextual (es como si se crearan Actions de un TActionList) Este ejemplo es en firemonkey Tambien estan los componentes de Tethering e Internet (los nuevos TNetHttp de XE8 creo), los sensores (LocationSensor, MotionSensor, OrientationSensor), Bluetooth y BluetoothLE. Tambien vienen los VCL Styles (incluidos los de Windows10) En fin,m que no esta tan mal! |
#4
|
||||
|
||||
Sabía que esta disponible la unidad DB.pas pero eso no es garantia de que estuvieran los data-ware. Y no recordaba haber leído en la hoja de especificaciones si estaban.
Ahora que lo pienso tiene sentido que esten. Ya que si dejas abierta la instalación de componentes de acceso a base de datos o que amplíen los data-ware tenes que darles su uso. Definitivamente voy a instalar Starter. Saludos |
#5
|
||||
|
||||
En realidad la que está disponible es su versión precompilada DB.dcu (Data.DB.dcu). Dado que, tal como sucede con las versiones trial, no incluye la gran mayoría del código fuente de sus bibliotecas nativas.
Cita:
Saludos. |
#6
|
||||
|
||||
Los data-aware son controles geniales, que no tienen muchos imitadores. Quizas FoxPro e ironicamente acces son los únicos con un modelo similar.
Durante mucho tiempo intente creer que el modelo OO era el mejor; que hay que "abstraer" y que hay que crear un montón de clases para lograr algún objetivo teórico e ideal. Pero eso solo ocurre porque por mucho tiempo solo estuve *dentro* de entornos OO, y SIEMPRE resultaba un lio la conectividad con las BD. Cosa que no ocurria con FoxPro; y que en parte se evidencia con los controles data-aware (que están enfocados a manejar algo parecido a tablas y no a objetos). ---- Ahora que he expandido horizontes con lenguajes funcionales y estudiado otros paradigmas, me he dado cuenta que el modelo OO es solo uno entre tantos, y que es mucho mas simple no intentar pelear contra la naturaleza de las BD y usar lo que estas tienen. Lo que ha estado tomando algo de fuerza es usar los objetos POCO (Plain-Old-Objects) que es lo que se usa cuando un lenguaje no tiene soporte a STRUCTS y usar clases/funciones para operar en ellos; a la vez de dejar de lado los ORM y usar de forma mas directa el SQL. COn lo de dataware es triste, pero la gente de JS no esta dando la pela y estan muy avanzados. Cosas como React (https://facebook.github.io/react/) y el modelo Reactive muestran que el modelo data-aware que entendemos en Delphi solo tiene un problema: Es MUY limitado. En vez de negarlo, se puede hacer aun mas poderoso. Este es un ejemplo de una libreria reactiva: http://reactivex.io/ El punto es que hacer el binding entre la interface y los datos u clases es algo que si o si hay que hacer. El modelo OO complica la cosa, y el modelo mas funcional lo simplifica, pero afortunadamente no es muy dificil de hacer una version combinada. La otra alternativa, es lo que hemos hecho: Inventar nuestra propia manera de hacer binding, solo que ad-hoc.
__________________
El malabarista. Última edición por mamcx fecha: 28-08-2016 a las 06:39:21. |
#7
|
||||
|
||||
Los controles dbaware, guardadas las distancias, son como PHP. Si no te tomas la molestia de usarlos como se debe, es seguro que piensas que son lo peor de la creación. Eso de que generan código espaguetti es sólo si no se toma uno el tiempo de separar los formularios de los módulos de datos, colocar en estos últimos los datasets y no andar poniendo código sql insertado al vuelo en el onclick de un botón.
LineComment Saludos |
#8
|
||||
|
||||
Cita:
Es conocido y de esperarse que venga con muy pocos fuentes, que dicho sea de paso también lo aclaran en la hoja. Cita:
Saludos, |
#9
|
||||
|
||||
Cita:
Hola Tambien habia leido sobre el TBufDataset pero su aproximacion al ClientDataset es aún limitada a mi parecer. Ademas que lo siento muy vinculado a los controles SQLDB (De él deriva el TSQlQuery). A mi me gustaba usar el evento Beforeupdaterecord del Datasetprovider para personalizar la forma de aplicar las actualizaciones; pero en el bufdataset no existe un evento similar, es mas el metodo applyupdates es un procedimiento en vez de una funcion como en el clientdatset. Saludos.
__________________
Caminante, son tus huellas el camino y nada más; Caminante, no hay camino, se hace camino al andar. Antonio Machado |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Viernes 17 Junio 2016 ¡C++ Builder starter GRATIS¡ | WHILENOTEOF | Noticias | 20 | 18-06-2016 17:12:03 |
Delphi XE3 Starter, ¿vale la pena? | to_to | Delphi para la web | 4 | 09-01-2013 07:13:14 |
Donde descargo C++ o Delphi STARTER | cmm07 | Varios | 8 | 23-07-2012 10:41:52 |
Builder y Delphi Starter Edition | Neftali [Germán.Estévez] | Noticias | 68 | 17-02-2011 19:47:40 |
|