programacion en capas

[Carton Jeston]

He buscado por el foro el hilo mas apropiado para preguntar sobre capas, porque ya hay respuestas previas muy validas que evitan repetir preguntas innecesarias. Voy a intentar que sea este un poco mas general, teniendo en cuenta que sigo el blog de Fernando D.Bozzo y ya llevo tiempo aplicando lo que he aprendido alli. Asi que decidi reciclarme desde cero, asi que ante la minima duda por tonta que parezca no la dare por supuesto o volveria a las andadas :D

Viendo algunos programas en otros hilos me hacen dudar si lo habia entendido bien o no como funciona las capas. Por ejemplo en un formulario de clientes tenemos unos campos con codigo (marco con asterisco) y otros no (sin validaciones ni nada):

*CODIGO
NOMBRE
DIRECCION
POBLACION
*DNI (documento identidad)

En CODIGO y DNI en el controlsource apunto a la clase de negocio que es donde tengo todas las rutinas que lo gestionan. En el resto solo son campos de almacenamiento que de momento no tienen ningun control y apuntan directo a la base de datos como toda la vida en el controlsource (cliente.nombre, cliente.direccion, cliente.poblacion) ¿esto que hago es correcto?

[Carlos Hidalgo]

Todos los controles deben apuntar al objeto de negocio.. Y este se encarga de procesar la info y enviarlo a la capa de datos.

Asi si cambias de dbf a sgbd no tendrias que modificar nada de tus forms.

Un ejemplo a groso modo..

En el boton eliminar de un form iria algo asi:

_screen.oNegocio.Elimimar(cTabla,nRegistro)

Y en el objeto de negocio iria algo asi en el metodo "Eliminar"

LParameters tcTabla, tnRegistro

lcSql='Delete from '+ tcTabla+ ' where codigo= '+ transform(tnRegistro)

_screen.oConexion.SQL(lcSQL)

Y en la capa de conexion (o acceso a datos) el metodo que envia las consultas al servidor o dbf

LParameters tcSQL

Sqlexec(nCon,tcSQL)

Asi va la idea.. Cada capa separada con sus propios metodos.. 

Forms>Negocio>Conexion (o acceso a datos).

Tanto la capa de negocio como la de conexion (o acceso a datos) se deberian compilan como dll para despues instanciarlas... De esta forma estariamos hablando realmente de capas..

Saluditos.

Adjunto grafica.

[Antonio Meza]

Si y No !!!! jajajajajaj

El tema es sencillo pero complicado jajaja, los Cursores de VFP no son bien vistos para usar entre capas, es decir deberías usar variables, propiedades, array, clases, etc pero NO usar cursores, por lo tanto siguiendo la regla básica de las capas NO debes usar cursores pues no encajan ya que son exclusivos de unos pocos lenguajes y en la mayoría no existen los cursores y es por ello que no los aplican!!

Ahora en mi caso particular difiero de ello, pero OJO!!!! cuando estamos usando solo VFP y no usar Cursores es un verdadero desperdicio del lenguaje, para mi un Cursor es una librería o clase que ya tiene N cantidad de funciones programadas listas para reutilizarse, es decir si un Cursor de VFP lo ves como si fuera una CLASE entonces encaja perfectamente en la programación orientada a objetos y sobre todo para ser reutilizada en CAPAS!!!!

Aquí ya entran los gustos y disgustos de cada quien, pero insisto no usar los Cursores de VFP y si programas en VFP pues no sabes programar en VFP jajajajaja y ahí te vas mas si no usas el ControlSource tampoco sabes programar en VFP jajajajajaj y una mas para rematar si no sabes usar el Valid() pues no sabes programar en VFP jajajajaja otra mas?? para el viernes jajaja

Conclusión personal!!! Usa Cursores y ControlSource!!!! pues estas programando en VFP no en otro lenguaje!! pero separando las capas!!! checa el siguiente link

https://foxydb.wordpress.com/2015/12/02/vfp-y-sus-cursores-de-datos-utilizarlos-como-un-objeto/

saludos

Antonio Meza

[Carton Jeston]

Y para que no se vaya la cosas por las ramas y acabemos hablando de control de codigo fuente y plasticscm... :D

Viendo el diagrama, un objeto que no requiera validaciones, procesos, calculos o control de errores, como la descripcion de un articulo, direccion o poblacion ¿puede apuntar a la base de datos directamente desde el controlsource? Asi es como lo estoy haciendo hasta ahora ¿ es correcto?

CODIGO (codigo del articulo) ->negocio
NOMBRE->directo a tabla
DIRECCION->directo a tabla
POBLACION->directo a tabla
DNI (documento identidad)->negocio

Me comentas que todos los controles deben apuntar al objeto negocio, ¿lo correcto seria todo a negocio?

[Carlos Hidalgo]

Afirmativo... Todos los controles

Vayámonos a la teoría

https://es.wikipedia.org/wiki/Programaci%C3%B3n_por_capas

Capas y niveles[editar]

1. Capa de presentación: la que ve el usuario (también se la denomina "capa de usuario"), presenta el sistema al usuario, le comunica la información y captura la información del usuario en un mínimo de proceso (realiza un filtrado previo para comprobar que no hay errores de formato). También es conocida como interfaz gráfica y debe tener la característica de ser "amigable" (entendible y fácil de usar) para el usuario. Esta capa se comunica únicamente con la capa de negocio.
2. Capa de negocio: es donde residen los programas que se ejecutan, se reciben las peticiones del usuario y se envían las respuestas tras el proceso. Se denomina capa de negocio (e incluso de lógica del negocio) porque es aquí donde se establecen todas las reglas que deben cumplirse. Esta capa se comunica con la capa de presentación, para recibir las solicitudes y presentar los resultados, y con la capa de datos, para solicitar al gestor de base de datos almacenar o recuperar datos de él. También se consideran aquí los programas de aplicación.
3. Capa de datos: es donde residen los datos y es la encargada de acceder a los mismos. Está formada por uno o más gestores de bases de datos que realizan todo el almacenamiento de datos, reciben solicitudes de almacenamiento o recuperación de información desde la capa de negocio.

[Antonio Meza]

Vas por mal camino!!!

O bien usas objetos para todo o bien usas cursores para todo, porque hacer una combinación de ambos tu programa sera una pesadilla de viernes 13 jajajaja, es decir al rato no vas a saber si un dato proviene de un objeto o proviene de un cursor.

Tuviste el tiempo de leer mi mensaje y el link? tienes alguna duda!!!

Por lo que veo Carlos Hidalgo usa capas con objetos como lo marca la teoría de las cuerdas jajaaj es broma!!! como lo marca la teoría de las capas, es decir esta perdiendo la potencia del lenguaje que en este caso es VFP. Esta perfecto como él te lo dice es 100% correcto usar objetos enlazados a datos, pero es doble o incluso triple trabajo o cuádruple el usar objetos en VFP.

La potencia de VFP esta en el manejo de los Datos y no aprovechar su mejor característica pues es un verdadero desperdicio del lenguaje.

saludos

Antonio Meza

[Irwin Rodriguez]

Totalmente de acuerdo con Antonio. Se puede trabajar en capas con VFP pero estarías desaprovechando la increible rapidéz que éste te ofrece para el tratamiento de datos mediante DataEnvironment + CursorAdapter. Para verlo metafóricamente sería como que tuvieras un Ferrari para usarlo de transporte escolar.

Saludos...!

--

Irwin Rodríguez

Analista Programador

+593 0994903424
Latacunga - Ecuador

[Víctor Hugo Espínola Domínguez]

Es cierto que el cursor de VFP es una maravilla, uso campos de cursor en los control source de los objetos del formulario, pero usar objetos también tiene sus ventajas, se puede pasar entre capas, eso no se puede con cursores. El cursor no puede usarse como parámetro y por lo tanto debe compartirse entre las capas, si el programa es monolítico (un solo .exe) no hay problemas, pero si quieres tener un servidor com en alguna(s) capa(s) estás fregado con el cursor, justamente esa posibilidad de tener capas en dlls (hasta pueden estar en diferentes pcs)  es una de las características apreciadas de la programación en capas.

Saludos,

Víctor.

Lambaré - Paraguay.

[Carton Jeston]

Vamos por capas... digooo por partes.

1) ¿estais todos de acuerdo que todos los campos del formulario deben apuntar a un objeto de negocio? Carlos dice que si. Yo pensaba que era algo mixto.

2) La discrepancia sobre los cursores ¿es por tener las tablas en el enviroment de los formularios?. Con dbf lo tengo asi, pero cuando me pase a foxydb no creo que sea viable.

3) Antonio, he leido tu enlace y comprendo lo que dices. Tambien uso y abuso de cursores pero tengo que organizarlo de algun modo pensando en una portabilidad futura. No me da pereza tener que crear a mano todo si a la larga me crea problemas irresolubles como tener un ERP que funciona bien pero da miedo tocar nada :D

Vamos a reforzar la idea y seguimos debatiendo sobre las diferentes opciones con sus pros y contras sin desviarnos de la Senda del Zorro Dorado que ya me la estan mareando :D :D :D

[Patricio Muñoz]

Carton

He estado leyendo este hilo, te pregunto algo... sabes programar en oop?, te lo pregunto porque para trabajar en capas es necesario programar en esa técnica.

Bendiciones

--

Saludos

Patricio Muñoz

Pro&Tech

Analista en Sistemas

[Víctor Hugo Espínola Domínguez]

>1) ¿estais todos de acuerdo que todos los campos del formulario deben apuntar a un objeto de negocio? Carlos dice que si. Yo pensaba que era algo mixto.

Lo importante es que el control sea "alimentado" por "algo" (propiedad de un objeto, campo de un cursor, variable o array) cuyo valor se haya originado en la capa de negocios. El concepto primordial es que la capa de presentación (UI) solo puede comunicarse (recibir/enviar datos) con la capa de negocios (BI). Es por eso que la Data Environment con o sin Cursor Adapter no se deben usar en el formulario.

>2) La discrepancia sobre los cursores ¿es por tener las tablas en el enviroment de los formularios?. Con dbf lo tengo asi, pero cuando me pase a foxydb no creo que sea viable.

En la programación por capas es un contrasentido usar data environment, el formulario debe recibir o enviar datos solamente desde/hacia la BI.

Saludos,

Víctor.

Lambaré - Paraguay.

[Antonio Meza]

Victor es correcto lo que comentas, pero hay que ser realistas la mayoría aun programa con DBF tu crees que usar DBF accediendo a ellas por medio de DLL o Servidores Com desde otras PC va hacer lo mejor? en vez de eso simplemente acceder a un servidor de base de datos y asunto arreglado y quitarse toda esa gran maratonica división de DLL y servidores COM??

Y como es que no puedes pasar cursores entre capas ahí si no te entendí podías comentar mas al respecto? porque es algo que uso mucho, en ves de crear propiedades a la clase y luego obtener el cursor y asignar los valores del cursor a las propiedades, luego destruir el cursor, pues simplemente uso el propio cursor como si fuera una clase y sus propiedades!!!

El tema de capas no es muy amplio en internet, y normalmente lo que hay va enfocado a otros lenguajes, pero VFP tiene Cursores algo que no vas a encontrar en otros lenguajes y por lo tanto insisto hay que utilizarlos y no evitarlos.

saludos

Antonio Meza

[Antonio Meza]

Como dice Victor usar el DataEnvieronment al usar capas ya no es necesario, en vez de beneficiarte te complicaría mas las cosas, pues la capa de Datos debe sustituir el DataEnvieronment del formulario. Respecto a CursorAdapter prefiero SqlExec() porque con CursorAdapter te adaptas a el, y con SqlExec() tienes acceso y el control manual al servidor de base de datos y no todos son iguales. Algunos dirán que CursorAdapter usa ADO que es mas rápido que ODBC y es cierto PERO!!! lo que muchos no saben que no siempre existe un controlador nativo ADO para el servidor y se usa una capa intermedia de ODBC, es decir al final vienes usando ODBC entonces para que complicar mas las cosas jajajaja

saludos

Antonio Meza

[Antonio Meza]

Extremo es muy valiosa tu pregunta, si no se conoce a fondo lo que significa y programar en OOP (Programación Orientada a Objetos) el intentar usar Capas va hacer una total pesadilla, pues todo parte de la OOP!!!

Y por las preguntas de Carton todo parece ser que no ha estudiado OOP!!! 

saludos

Antonio Meza

[Víctor Hugo Espínola Domínguez]

"no se puede pasar cursores entre capas" significa que un cursor no puede usarse como parámetro de función o procedimiento o método o programa, lo que se puede hacer es compartir la sesión de datos entre el módulo llamador y el llamado y entonces el cursor es accesible en ambos módulos, pero esta mala práctica se denomina acoplamiento fuerte.

Por supuesto que se usan cursores en todas las capas, en la capa de datos mediante ODBC se obtiene un cursor desde el servidor, en la capa de negocios se efectúan procesos sobre cursores y en la capa de presentación se usan para alimentar grids, combos, list box, etc...

Saludos,

Víctor.

Lambaré - Paraguay.

[Carlos Hidalgo]

Carton, no puede ser mixto porque entonces ya caerías a la programación espagueti. la Interfaz no debe comunicarse con la capa de datos. Tiene que hacerlo a través del negocio.

Y obviamente seguirás usando cursores para manejar datos en los forms que lo requieran (grid, detalles), pero para pasar la información hacia el Negocio (BI) deberás usar bien sea Arrays, xml o Json. ( con Xml puedes usar la función nativa de fox CURSORTOXML y XMLTOCURSOR). 

Una ventajas de programar en capas:  

Supongamos que dejas de utilizar odbc para conectarte a tu bd y te quieres conectar por webservice (los datos aqui se manejan con xml o json) solo tendrías que hacer algunos ajustes a tu capa de negocio y tu interfaz queda intacta.

Saludos

[Víctor Hugo Espínola Domínguez]

La POO es una versión nueva y mejorada del paradigma conocido como programación estructurada, todas las buenas prácticas de la programación estructurada se aplican en la POO, la cual implementa nuevas técnicas y conceptos.

Se puede "progamar en capas" sin recurrir a la POO, se tiene un prg con las funciones referentes al acceso de datos, otro prg para la BI y otro para la UI, y en  vez de crear objetos simplemente se llaman a funciones/procedientos respetanco las vías de comunicación entre capas

Me atrevo a opinar que los que encuentran difícil la POO es porque no dominan o desconocen la programación estructurada.

Saludos,

Víctor.

Lambaré - Paraguay.

[Irwin Rodriguez]

mmmmm.... Espagueti...!!!

[Antonio Meza]

No sera que tu vez al cursor de diferente forma? para mi un cursor es una Clase y los campos son sus propiedades, y teniendo claramente esa visión al final no es lo mismo? es decir en vez de crear propiedades a la clase usas el cursor!! desde luego no confundir las propiedades que apuntan a datos con las propiedades que requiere la clase para su uso.

He incluso uso sesiones privadas de datos y el intercambio de información sigue siendo natural no he tenido que compartir sesiones de datos para poder ver el cursor entre diferentes capas.

O sera que estamos hablando de diferente tema?

saludos

Antonio Meza

[Carlos Hidalgo]

Dear Master Antony (jijiji)

Y como es que no puedes pasar cursores entre capas ahí si no te entendí podías comentar mas al respecto? porque es algo que uso mucho, en ves de crear propiedades a la clase y luego obtener el cursor y asignar los valores del cursor a las propiedades, luego destruir el cursor, pues simplemente uso el propio cursor como si fuera una clase y sus propiedades!!!

No es posible pasar un cursor de una capa a otra porque las capas se comunican a través de métodos, dichos métodos se alimentan con parámetros. Y un cursor no se puede enviar como parámetro. Para ello hay que convertir el cursor a xml o json.

[Carlos Hidalgo]

​La única forma de entenderlo es llevándolo a la practica​.

Porque yo tampoco lo entendía hasta que lo lleve a la practica.

[Antonio Meza]

ahhhhhh ya ya ya ya jajajajajajaja 

Es correcto no se puede pasar un Cursor como parámetro!!! es decir hacer lo sigueinte

obus.Calcular(cursorNombre)

Pero eso no es necesario hacerlo, es decir siempre he usado cursores y no he tenido que hacer eso!!! si voy a calcular pasando un valor uso asi

oBus.Calcular(cursorNombre.campoNombre)

Que seria lo mismo que hacer esto con una clase y su propiedad

oBus.Calcular(oBus.Importe)

O en su defecto

oBus.Calcular()

Y dentro del método uso el cursor pues esta esta en memoria, porque insisto para mi un cursor es una Clase no es una tabla o dbf!!! a ver si me explique!!!

saludos

Antonio Meza

[Víctor Hugo Espínola Domínguez]

Por supuesto que vemos al cursor de diferente forma, para mí el cursor es un tipo especial de tabla y tu dices que es una clase, puede ser un objeto de la clase cursor solo en la data environment, y como objeto tiene muy poca utilidad pues casi todas sus propiedades son de solo lectura, además la DE no es admitida en la programación en capas.

Saludos,

Víctor.

Lambaré - Paraguay.

[Antonio Meza]

No uso DE (DataEnvieronment) lo use con Vistas Locales, pero desde que uso Capas y FoxyDb no lo uso!! a lo mejor confundiste mi comentario con el de otro que si lo usa.

Y realmente un Cursor para mi es como una Clase, en mi comentario anterior dije que es una clase, pero realmente lo que quiero decir es que lo veo como una Clase, solo para que quede asentado en el acta jajajajajaj

saludos

Antonio Meza

[Antonio Meza]

Carlos Hidalgo!!! comentas:

Y obviamente seguirás usando cursores para manejar datos en los forms que lo requieran (grid, detalles), pero para pasar la información hacia el Negocio (BI) deberás usar bien sea Arrays, xml o Json. ( con Xml puedes usar la función nativa de fox CURSORTOXML y XMLTOCURSOR). 

Esta es la parte que en lo personal lo veo como doble o triple trabajo, si ya tienes un cursor en memoria asignado a un Grd donde realizaste cambios, porque debes convertirlo para realizar las operaciones en las capas? porque no usarlo directamente? no se si me explico? partiendo de la idea inicial que en VFP los cursores son su potencial que en otros lenguajes no existen!!!

Una ventajas de programar en capas:  

Supongamos que dejas de utilizar odbc para conectarte a tu bd y te quieres conectar por webservice (los datos aqui se manejan con xml o json) solo tendrías que hacer algunos ajustes a tu capa de negocio y tu interfaz queda intacta.

Realmente en la capa de Negocios y Presentación no tiene porque realizar cambios, seria solo en la capa de Datos que es la que se encarga de obtenerlos si es que cada capa fue bien programada y es independiente una de otra.

Supongamos que los datos los obtienes de un WebServices, y te devuelve un JSON donde viene el detalle de la factura, y quieres mostrar esos datos en un Grid, que es lo que tienes que hacer? Crear un Array y pasar los datos del JSON al Array, muestras los datos del array en el GRID e incluso cambias valores y luego tienes que pasar los nuevos datos del Array al JSON para retornar al WebServices si se quiere actualizar es correcto?

Suponiendo que es así, entonces como sabes que cambios realizaste en el Array? un ejemplo la factura tiene 50 items, y de ellos solo cambiaste el item 30, ahora te toca enviar de regreso por WebServices esa información, lo que tienes que hacer es enviar los 50 items de regreso, pero si usaras un Cursor en vez de un Array solo seria necesario enviar 1 solo item que fue el que cambio realmente, porque con los cursores puedes saber que campo y registro cambio, eso es solo una de las muchas ventajas que hay al usar Cursores y no propiedades, Array y otras yerbas en VFP.

saludos

Antonio Meza

[Carlos Hidalgo]

Realmente en la capa de Negocios y Presentación no tiene porque realizar cambios, seria solo en la capa de Datos que es la que se encarga de obtenerlos si es que cada capa fue bien programada y es independiente una de otra.

Correcto es la capa de datos. Me equivoque.

"Errar es de humanos", echarle la culpa a otro es mas humano todavía jajaja

Suponiendo que es así, entonces como sabes que cambios realizaste en el Array? un ejemplo la factura tiene 50 items, y de ellos solo cambiaste el item 30, ahora te toca enviar de regreso por WebServices esa información, lo que tienes que hacer es enviar los 50 items de regreso, pero si usaras un Cursor en vez de un Array solo seria necesario enviar 1 solo item que fue el que cambio realmente, porque con los cursores puedes saber que campo y registro cambio, eso es solo una de las muchas ventajas que hay al usar Cursores y no propiedades, Array y otras yerbas en VFP.

Es que los cursores se siguen usando, no he dicho que no. Las otras yerbas son solo para comunicarse entre capas. 

La capa de negocio envía un Array a la interfaz, la UI la convierte a Cursor y aprovecha las ventajas del cursor que tu mencionas, luego vuelve a enviar los datos que se modificaron, como lo mencionas, pero nuevamente debe convertirlo a  array o xml o alguna yerba para que lo entienda la capa de negocio y luego datos.

Saludos

[Víctor Hugo Espínola Domínguez]

Json se debería convertir a cursor.

Saludos,

Víctor.

Lambaré - Paraguay.

[mapner]

Porque convertir los datos a XML, JSON, etc, para pasarlos entre capas? La respuesta es, que hay que convertirlos si la separación entre capas es física además de lógica.

[Antonio Meza]

Por fin si o no? jajajajajaja o sea dicen que no se deben usar cursores, pero luego dices que si ya no entiendo jajajajaj

saludos

Antonio Meza

[Carlos Hidalgo]

jajajaja

Yo no he dicho no se usen cursores.

Donde no se pueden usar es para enviar datos de una capa a otra.

[Antonio Meza]

Exacto acabas de enriquecer el tema!!! si la capa de datos es una DLL hecha en C# por ejemplo pues definitivamente no puedes enviarle un cursor debe ser una capa intermedia según sea el caso un XML  JSON, etc.

Pero insisto si al final debo retornar un XML o JSON, o TXT, XLS, etc en VFP trabajo la información con un cursor y luego realizo un proceso de conversión para enviar al destino, es lo mismo que hago con FoxyDb, todo se usa por medio de Cursores y al final se generar el SQL correspondiente para enviar al servidor, es es lo que quiero que aprovechen y no lo hacen por seguir otros lenguajes donde no existen los cursores.

Prefieren inventar el hilo negro en VFP!!! jajajaja

saludos

Antonio Meza

[Fernando D. Bozzo]

Hola!

Acabo de ver que estás con este tema y leí todos los comentarios, que me parecen realmente muy buenos ya que es un tema amplio, interesante y muy útil.

Solo me interesa dejarte algunas ideas simples que pueden ayudarte a llevar esto de una forma más fácil y práctica.

Para empezar, si estás pensando en usar capas es porque ya decidiste que a futuro querés poder escalar a otra base de datos no-DBF (cliente-servidor, por ejemplo MariaDB, PostgreSQL, Oracle, etc) e incluso podría pasar que más adelante incluso a otro lenguaje.

Para hacerlo fácil, yo veo la programación en capas de la misma forma que un módulo de proceso batch, o sea: con 2 capas tiene que funcionar (negocio y datos), y la tercera es solamente para poder comunicarse con el usuario (interfaz).

Una parte de la programación es el negocio y sus reglas (validaciones, procesos de cálculo, etc), ésta se encarga de solicitar a la capa de datos lo que necesita, tanto para consultar como para insertar o eliminar, y finalmente la interfaz sirve para que el usuario pueda seleccionar opciones y parametrizar las llamadas al negocio. En cualquier caso, la interfaz se puede reemplazar por cualquier otro método de entrega de parámetros, incluso podrías usar un archivo de configuración de parámetros con exactamente el mismo resultado, y justamente eso --para mí-- es una de las mejores ventajas de esa separación, ya que te permite no solo poder usar los mismos procesos que llamas desde la interfaz pero desde un proceso desatendido, como por ejemplo un proceso masivo de facturas u otro, sino que lo mismo lo podés usar para Unit Testing, pudiendo crear un set de datos de prueba para diferentes casos de uso y así volver a llamar a la misma lógica de negocio que llamas desde la interfaz o desde un proceso batch.

Como ves, una gran ventaja de todo esto, al tener separadas las capas, es la reutilización de componentes, y eso también te ayuda a mejorar la encapsulación. Al final es una espiral de técnicas y buenas prácticas que empezás a usar, y de pronto te das cuenta que ciertos módulos que hacen una sola cosa y que encapsulaste bien también los podés encadenar para crear un nuevo proceso, como si fueran piezas (funcionalidades) encadenables.

Respecto de los cursores, y siempre teniendo presente lo anterior y lo que comentó Victor Hugo ("no se pueden pasar cursores entre capas"), hay que ver a los cursores como un mecanismo eficiente de la interfaz para compartir datos entre interfaces y hasta para realizar selecciones deopciones, pero cuando hay que pasar información al negocio, hay que hacerlo con tipos de datos "normalizados" que entiende cualquier componente, esto es: string o arrays.

Dicho lo cual, si querés usar un cursor como origen de datos "temporales" de edición, para luego pasarlos al negocio mediante una serialización en array, es perfectamente válido, ya que el cursor lo estarías usando como un mecanismo eficiente de intercambio de datos internos para la interfaz, pero que en su estado puru nunca llegarán al negocio.

La otra forma es usar un objeto de datos, como comento en mi artículo de capas, para usar sus propiedades como controlsource, lo que tiene como ventaja añadida que ese mismo objeto de datos lo podés pasar de parámetro a la capa de negocio para que realice las validaciones o procesos usándolo directamente.

Creo que se puede aprovechar buena parte de los cursores dentro de las interfaces, siempre que se los tenga en cuenta como "contenedores temporales" de datos para manipularlos en la interfaz, y nada más. Al considerarlos como parte de la capa visual, quedaría más clara su separación de la capa de negocio y datos, ya que en ese contexto al quitar la interfaz (y sus cursores) los podrías reemplazar perfectamente por otra interfaz en otro lenguaje que invoque a los mismos objetos de negocio usando el mismo mecanismo (pasando strings o arrays) sin tener que realizar cambios en el negocio.

Que tengas buen comienzo! y espero haberte podido ayudar a aclarar algún concepto :D

[Carton Jeston]

Bueno, aprendi a programar OPP con Borland C++ a mediados de los 90 y apenas lo toque con clipper, aunque para mi fue un poco catastrofico mi paso a windows por foxpro 2.6  con el tiempo justo para migrar sistemas tal cual y no fue hasta VFP6 cuando empece a usar la OPP de nuevo. Y eso de ser autodidacta, contrareloj y sin la informacion que hoy de dispone, mi base es un tanto irregular con la sensacion a veces de "ese dia no fui a clase". Ya hace un tiempo que me estoy reciclando en mi tiempo libre, mi aplicacion funciona como un reloj pero ya no me resulta suficiente y he pensado en aprender todo desde cero y no dar todo por hecho. Asi que no se preocupen de lo que se o dejo de saber, solo pretendo quitarme vicios en la programacion y aprender de los que ya hicieron el camino correcto. ;-)

Mencionaron el uso de DE y cursores (no fui yo) y me resulto ilogico con la idea de la programacion por capas tal y como veo que explica Fernando. Y explica Carlos sobre mi duda original, que el uso mixto de campos y objetos de negocio lleva a la programacion espaguetti me aclaro ese punto, cuando oigo espaguetti ya dejo de discutir. :D :D :D

 Ahora bien, la discusion me gusta por su diversidad de opiniones, aunque no estoy de acuerdo en limitarse ni al lenguaje, ni al uso de dbf ni si usaras dll o no. Tampoco que cueste hacer una cosa el doble, a mi me preocupa y mucho que al final del camino me cueste diez veces mas mantenerlo por no trabajar mas al principio. (Ojo no es una critica contra Antonio), jajajaja

Animo a seguir dando ideas y que cada uno adopte las que mejor considere.
un saludo

[Antonio Meza]

Ahora bien, la discusion me gusta por su diversidad de opiniones, aunque no estoy de acuerdo en limitarse ni al lenguaje, ni al uso de dbf ni si usaras dll o no. Tampoco que cueste hacer una cosa el doble, a mi me preocupa y mucho que al final del camino me cueste diez veces mas mantenerlo por no trabajar mas al principio. (Ojo no es una critica contra Antonio), jajajaja

Carton, creo que mal interpretas mis comentarios, pues soy enemigo de hacer algo solo porque funcione, me gusta saber el porque y como es que funciona, entendiendo eso, no voy a crear una DLL porque se perfectamente para que sirven y en mi caso no tendrá utilidad, no es porque no quiera trabajar de mas al principio si no que en la forma que tengo separado todo me seria mas difícil mantener DLL que no usarlas, no voy a compartir información con otros lenguajes por darte un simple detalle, no es mi idea, es como un servidor de base de datos prefiero aprovechar las cosas nativas del servidor de base de datos que crear o usar algo genérico por eso no uso CursorAdapter jajajajaj.

Se como funcionan las capas, se la responsabilidad que debe llevar cada una, y como lo he dicho en la forma que lo comento Victor, Carlos y Fernando es como debe ser, ahí no hay discusión, en lo que yo enfatizo es en la ventaja que tiene VFP con los cursores que no encuentras en otros lenguajes, tampoco me estoy limitando a VFP, mas bien estoy aprovechando lo mejor de el, y eso es lo que trato de explicar, pero pueden seguir usando como lo hacen y es correcto, pero desde mi punto de vista PERSONAL!!!!! es mas trabajo y al final el resultado es el mismo e insisto cuando hablamos de VFP. si habláramos de capas en C# por ejemplo no hubiera comentado nada jajajajajaja porque ahí no hay cursores!!!

Si tu intención es compartir capas con otros lenguajes, es decir reutilizar entonces si o si debes hacer como lo dice Victor, Carlos y Fernando, pero si tu intensión no es esa, entonces que caso tiene hacerlo? no se si me explico!!!

saludos

Antonio Meza

[Antonio Meza]

Excelente comentarios Maestro Fernando!!

Solo para que conste en el acta que mi intervención en el tema no es debatir como se deben usar las capas, se y me queda claro que en la forma que lo dice usted, lo dice Victor y Carlos es la correcta!!!

No se si tuvo oportunidad de leer el tema que comente en mi blog!!

https://foxydb.wordpress.com/2015/12/02/vfp-y-sus-cursores-de-datos-utilizarlos-como-un-objeto/

me gustaría pudiera comentar algo al respecto!!!

saludos

Antonio Meza

[Víctor Hugo Espínola Domínguez]

En mi primera participación en este hilo dije "Es cierto que el cursor de VFP es una maravilla, uso campos de cursor en los control source de los objetos del formulario,"

Uso cursores en las 3 capas, lo que dije y recalco es que el cursor no es un objeto ni clase y es imposible pasarlo como parámetro.

Saludos,

Víctor.

Lambaré - Paraguay.

[Carlos Hidalgo]

Y para que quede claro en mi tercer participación mencione: "Y obviamente seguirás usando cursores para manejar datos en los forms que lo requieran (grid, detalles),"

No se quien dijo que no se debían usar 😁😁😁

Happy Friday

[Antonio Meza]

Es correcto el cursor no es un objeto ni clase, y tampoco se puede pasar como parámetro!!! en eso estoy 100% de acuerdo, afirmativo, correcto, seguro, sin duda, exacto, perfecto!!! jajajaj

saludos

Antonio Meza

[Carlos Miguel FARIAS]

Como dije en otro hilo. Para mi un cursor es un objeto, tiene propiedades, tiene métodos, le podes pasar mensajes.

Y no lo pasas como parámetro, es cierto (bah, en python si se puede), pero como es un objeto, y yo mencione que un mensaje (comunicación entre objetos), también son objetos, por lo tanto si un objeto del sistema deja un cursor creado significa un mensaje para el objeto que lo encuentra.

Un ejemplo de viernes: Eres un objeto Marido, y si cuando llegas a tu casa, tu objeto Esposa te tira las valijas (objetos) por la cabeza, te está pasando un mensaje por parámetro, pero si cuando llegas, encuentras las valijas en la puerta, el mensaje te llega porque te dejo un objeto mensaje, y no te lo tiro por la cabeza (no te lo paso por parámetro).

Saludos: Miguel, La Pampa (RA)

Larga Vida y Prosperidad

Que la fuerza los acompañe, todo es un objeto (inclusive el todo), compuesto de sub-objetos, y así recursivamente hasta el bit.

[Antonio Meza]

Muy buen ejemplo y claro!!!!

Me gustaría conocer tu punto de vista sobre mi articulo, cuando tengas tiempo libre.
https://foxydb.wordpress.com/2015/12/02/vfp-y-sus-cursores-de-datos-utilizarlos-como-un-objeto/

saludos

Antonio Meza

[Carlos Miguel FARIAS]

Antonio:

En cuanto a tu artículo me parece correcto. De otra manera explicas lo mismo que comenté acerca de que los mensajes también son objetos, y que un cursor es un objeto y se puede utilizar como tal (y por lo tanto usarlo como mensaje).

Hay respondes a varias de las preguntas que hicieron en estos días varios colegas.

En cuanto a que es algo de VFP solamente, no te creas.

Si trabajas con COBOL con SQL, COBOL te maneja todo a través de cursores (las zanahorias que me costo entenderlo, haya por finales de los '80), si trabajas con SP, en los triggers de DELETE, INSERT, y UPDATE se crean dos cursores, cursor de lo de antes, cursor de lo de ahora. En el trigger de DELETE, el de antes, contiene todos los registros borrados, en el INSERT, el de ahora, todos  los registros nuevos, en el UPDATE, el de antes, contiene los registros como estaban antes del cambio, los de ahora, como quedan ahora.

Si hay un ROLLBACK  en DELETE, los registros borrados se restauran, en INSERT se quitan los nuevos (o no se insertan) y en UPDATE quedan con los datos de ANTES (.tableupdate y companía, te suena?)

En python, un acceso a una bd te revolea un objeto cursor que puede recorrerse en como un array (pero con las facilidades de python para hacerlo), la ventaja de python es que el cursor se puede pasar por parámetro.

Saludos: Miguel, La Pampa (RA)

Larga Vida y Prosperidad

Que la fuerza los acompañe

[Carton Jeston]

Recapitulando... o diria claudicando :D

En un formulario estandar sustitui controlsource donde CODIGO Y DNI son los unicos que tienen validaciones, incorrectamente usaba NOMBRE, DIRECCION y POBLACION directo al cursor/tabla solo cambiando los campos que requerian algun control o codigo.

CODIGO (codigo del articulo) ->negocio
NOMBRE->directo a tabla
DIRECCION->directo a tabla
POBLACION->directo a tabla
DNI (documento identidad)->negocio

Me han corregido y ahora se que tengo que dirigir todos los campos a negocio.

CODIGO (codigo del articulo) ->negocio

NOMBRE->negocio
DIRECCION->negocio
POBLACION->negocio
DNI (documento identidad)->negocio

La otra forma es usar un objeto de datos, como comento en mi artículo de capas, para usar sus propiedades como controlsource, lo que tiene como ventaja añadida que ese mismo objeto de datos lo podés pasar de parámetro a la capa de negocio para que realice las validaciones o procesos usándolo directamente.

Fernando, ¿Te refieres a que se puede usar asi?

CODIGO (codigo del articulo) ->negocio

NOMBRE->capa datos
DIRECCION->capa datos
POBLACION->capa datos
DNI (documento identidad)->negocio

Dime si es correcto esto o lo que me habian aconsejado de todos los campos de formulario tienen que apuntar a la capa de negocio.

Tambien esta el modo que usa Antonio y aunque lo he leido y puedo comprenderlo, no tengo experiencia para valorar que problemas o ventajas puede tener adoptarlo o como encajar en las capas sin comprometer la escalabilidad en el futuro.

Los motivos de meterme en este lio, es que ya hace tiempo tengo ese resquemor de que aunque la aplicacion funciona, el desarrollo a lo largo de los años ha sido muy variopinto, veo partes antiguas que dan risa o ganas de llorar segun el dia y otras bien estructuradas. Hay muchas diferencias entre una y otra sobre todo cuando añades o modificas con nuevas caracteristicas.

He llegado a la conclusion de que me sale mas rentable hacer una nueva version desde cero, pensando en la escabilidad, con las ideas claras de lo que tiene que ser al final, manejo de bases de datos con foxydb e incluso una portabilidad futura a otro entorno como lazarus o Xojo (este ultimo tiene casi todas las papeletas). Y sobre todo, tengo todo el tiempo del mundo para hacerlo, porque han sido las prisas en ciertos momentos las que me han conducido a esta situacion.

Todo esto lo digo, para aclarar que no menosprecio a ninguno de vosotros y estoy muy agradecido de la ayuda, de las diferentes opiniones que merecen ser estudiadas ahora o mas adelante. Siempre digo que lo mejor del fox esta en la comunidad de alborotadores que hay detras ayudando desinteresadamente ;-)

El mayor esfuerzo por mi parte es intentar olvidar todo lo aprendido e intentar meter las nuevas ideas y ya saben que no es facil los que han seguido este sendero previamente. Asi que no se tomen a mal si pido concreciones de cosas que pueden ser evidentes, porque mi mayor temor es dar algo por hecho y descubrir años despues que no era asi, cuando el problema explote en mi cara  :D

Se que por privado obtendria una sola respuesta mas sencilla, pero mi intencion al poner en el foro es animar a otros que estan indecisos en la zona de confort. Asi que todo lo que se ponga aqui valga tambien para todos ellos.

un saludo amigos

[Fernando D. Bozzo]

Hola:

Antes que nada es importante que sepas que no hay una sola forma de trabajar en capas, hay varias, y justamente eso es lo que permite poder implementar lo mismo de distintas formas, cada una de las cuales puede tener sus ventajas y sus desventajas dpendiendo de cómo estructures tu sistema y de qué tipo de funcionalidades elijas usar. No es fácil explicar todas estas opciones, pero voy a intentar dejarte algunos ejemplos con sus pro y contras y así de paso los demás también pueden comentar sobre los mismos ejemplos. Omito el control de errores para minimizar los ejemplos.

Ejemplo 1: Usando un objeto de datos temporal (compartible por parámetro)

Podrías tener una clase CL_DATOS_EDICION tipo custom con estas propiedades:

CODIGO
NOMBRE
DIRECCION
POBLACION
DNI

De la misma podrías hacerte un objeto oDatos, así:

thisform.oDatos = CreateObject("CL_DATOS_EDIDION")

Luego, en los ControlSource de los controles, podrías usar estas propiedades directamente:

txtCodigo.ControlSource = "thisform.oDatos.Codigo"

txtNombre.ControlSource = "thisform.oDatos.Nombre"

...

También podrías tener un clase de negocio CL_BUS como esta:

DEFINE CLASS CL_BUS AS Custom

   PROCEDURE Init

      * El negocio puede tener una referencia a la clase de datos (capa de datos)

      this.oDatos = CreateObject("CL_DATOS")

   ENDPROC

   FUNCTION Codigo_Valido( tcCodigo )

      RETURN NOT EMPTY( tcCodigo )

   ENDFUNC

   FUNCTION DNI_Valido( tcDNI, tcMsgError )

      IF (validacion que compruebe el DNI valido)

         tcMsgError = ""

         RETURN .T.

      ELSE

         tcMsgError = "El dígito de control no es válido"

         RETURN .F.

      ENDIF

   ENDFUNC

   FUNCTION Datos_Relacionados( tcCodigo, toDatos )

      RETURN THIS.oDatos.Datos_Relacionados( tcCodigo, @toDatos )

   ENDFUNC

   FUNCTION Calcular_Precio( tcCodArticulo, tnIVA )

      LOCAL lnTotal, lnCosto

      lnCosto = this.oDatosArt.Costo_Articulo( tcCodArticulo )

      lnTotal = lnCosto * tnIva / 100 && Esto es muy simplificado, solo para el ejemplo

      RETURN lnTotal

   ENDFUNC

ENDDEFINE

Y en el form podrías tener una instancia del objeto de negocio que tiene las validaciones, calculos, etc:

thisform.oBus = CreateObject("CL_BUS")

La clase de datos (capa de datos) podría llamarse CL_DATOS y ser de tipo custom:

DEFINE CLASS CL_DATOS AS Custom

   FUNCTION Datos_Relacionados( tcCodigo, toDatos )

      LOCAL llEncontrado

      SELECT * FROM LaTablaDeDatos.WHERE CODIGO = tcCodigo INTO ARRAY laDatos

      IF _TALLY > 0

         llEncontrado = .T.

         toDatos.NOMBRE = laDatos(1,2)

         toDatos.DIRECCION = laDatos(1,3)

         toDatos.POBLACION = laDatos(1,4)

         toDatos.DNI = laDatos(1,5)

      ENDIF

      RETURN llEncontrado

   ENDFUNC

ENDDEFINE

Luego, cuando quieras hacer las validaciones (por ejemplo en el VALID() de los controles) podrías tener algo como esto:

PROCEDURE txtCodigo.VALID()

   RETURN this.oBus.Codigo_Valido( thisform.oDatos.CODIGO )

ENDPROC

Se me está acabando la batería y no puedo enchufar ahora, así que resumo un poco.

Como ves, los datos en este ejemplo se toman siempre de las propiedades del objeto de datos de edición (oDatos), pero nunca de la propiedad VALUE del control!

Es importante en el form trabajar siempre con las propiedades del objeto de edición y no con los VALUE de los controles, porque los controles deben reflejar todo el tiempo los valores de estas propiedades.

Para los métodos de negocio, lo ideal es paras los datos separados, aunque dado el caso de tener que pasar muchos parámetros, puede ser mejor pasar un objeto de datos directamente.

Variantes que te permite este tipo de uso de objetos:

* Las validaciones de negocio se pueden invocar desde cualquier sitio, tanto formularios como desde el mismo negocio como de un proceso externo (automatización batch) como testing automatizado

* Al recibir los parámetros de los datos necesarios para trabajar, el método de negocio está encapsulado y es fácil de mantener

* El formulario se puede reemplazar por cualquier otro método que complete datos, por ejemplo un archivo con datos preconfigurados que se entregan directamente al negocio

* Los cambios de reglas de negocio las hacés solamente en la clase de negocio. No tenés que modificar ningún formulario (salvo que el cambio sea estético y no de validación)

* El formulario podría tener su propio objeto de negocio "visual" para controlar las actualizaciones de pantalla. Sirve para centralizar ciertas funcionalidades visuales que a veces se repiten entre formularios, entonces se encapsulan en una libreria de negocio "visual" (reglas visuales que no tienen nada que ver con las de negocio)

EN fin, te dejo esta idea y en otro momento veo si puedo poner otro ejemplo distinto.

Saludos!

[Carlos Miguel FARIAS]

🖖👏👏👏

[Fernando D. Bozzo]

Continuando con el ejemplo 1, otra opción para enviar los datos por parámetro en vez de uno a uno, es enviar el objeto de datos de edición:

FUNCTION Codigo_Valido( toDatos )

      RETURN NOT EMPTY( toDatos.Codigo )

ENDFUNC

La desventaja de esto es que no es obvio qué datos espera realmente el método, y podría pasar que para tener todos los datos necesarios para realizar la operación pudiera hacer falta otro objeto de datos, si se considera que cada objeto de datos de edición tiene un ámbito específico (clientes, artículos, etc). 

La unica ventaja de pasar un objeto de datos es que en el caso de necesitar más datos, simplemente se agregan en la definición de la clase y no hace falta agregar ningún parámetro en las llamadas intermedias, porque el dato va dentro del objeto pasado. 

En mi opinión esta opción sólo debería usarse cuando se deba pasar una estructura compleja de datos, pero nunca para llamadas normales donde se puedan pasar los parámetros independientes, porque además se perdería la autodocumentacion de los mismos. 

[mpulla]

Hola Carton.

Mi post no es para hablarte de programación en capas ya tienes buenos exponentes en el tema,si no comentarte mi opinion de xojo

Programo en Xojo un par de años, es fácil de aprender, es orientado a objetos, es tipado fuerte, multi plataforma, pero sus objetos son muy limitados, su comunidad es poco activa, cada versión que sacan ofrecen un montón de mejoras, que si las lees 85% son correcciones y el 15% mejoras entre comillas, tuvimos que quedarnos con la versión 2015 R2 ya que es la ultima que se puede correr en XP y en la empresa tenemos 50% pcs con XP.

Multi plataforma, acabas una aplicación, en Windows se ve relativamente decente, en linux la fuente es mas grande no caben en los labes, los controles se ven mas feos, no tienen una grilla decente, tiene un listbox feo y limitado, el reporteador es una farsa, la verdad no lo recomendaría.

Por favor no me preguntes porque trabajamos con Xojo.

Con VFP la vida era muy facil.

Ademas de centrarte en la programación en capas aprovecha el SGDB, hay muy potentes, estamos trabajando con Postgresql y la experiencia a sido satisfactoria.

Saludos.

Mauricio

[Carlos Hidalgo]

Y dentro del método uso el cursor pues esta esta en memoria, porque insisto para mi un cursor es una Clase no es una tabla o dbf!!! a ver si me explique!!!

Si el cursor se creo en la interfaz, claro que estará disponible en memoria

Si el cursor lo creo la capa de negocio o datos y esta "capa" es un prg que se instancio con algo asi 

      Set Procedure To negocio.prg

     oNegocio=Newobject("Onegocio","Negocio.prg")

También estará disponible en memoria.

Pero si el cursor lo creo la capa de Negocio o Datos que hemos compilado como dll o exe independientes (Que sería lo correcto para poder decir que programamos en capas) el cursor NO estará disponible en memoria, sino que se creara dentro de la capa y solo ella tendrá acceso al mismo, solo se puede acceder a los registros a través de métodos y propiedades.

Por lo tanto un cursor que se crea en una capa no se puede pasar a la otra capa, solo si se convierte a array, xml, json o alguno otro por ahi de tipo string.

No se si me explique. Como dije, solo se entiende hasta que se lleva a la práctica.

Saludos

Y ya casi es Viernes

Preparen su capa y el antifaz

[Carlos Miguel FARIAS]

Los cursores siempre están en memoria, aún los de un SGBD externo.

Que este en la capa datos, no escapa que pueda accederse desde la capa negocio o aun de la capa interfaz.

Fox, a veces pagina a disco y crea archivos temporales, pero solo si la RAM está muy ocupada.
Saludos: MIgue

[mapner]

Con el tema cursores, me parece que se confunde el tema de separación de capas físicas y capas lógicas. Un cursor local es una estructura temporal donde su ciclo de vida está asociado a la sesión de datos a la que pertenece y es visible dentro de esa sesión de datos. La plena visibilidad de cursores entre las capas iría un tanto en contra de lo que es el encapsulamiento de las clases que componen cada capa. El que todas las clases de cada capa residan en forma lógica en un solo exe monolítico puede ser una circunstancia, pero si no se respeta la separación y encapsulamiento de cada una de ellas se atenta contra el sentido del diseño. Un cursor que tenga plena visibilidad por varios componentes del sistema es casi como una variable pública, con el peligro que ello conlleva. Saludos.

[Carlos Hidalgo]

👏👏👏✌

[Carlos Miguel FARIAS]

Las capas son niveles de abstracción, no las veo como clases son formas de separar los procesos lógicos para poder modificar uno u otros y no afectar uno con los cambios en los otros.

Por ejemplo: Si en la interfaz con el usuario muestras una grilla. Tomas los datos en una capa datos, la conviertes a un array, o json o xml, lo pasas por parámetro a negocio (que puede modificar el array o no y luego lo pasas al array a la grilla?

Fíjate que hablando de clases y objetos, una grilla de fox es un objeto, y puede recibir como mensaje que el recordsource sea una tabla, un cursor, una sentencia SQL etc.

En un formulario, que también es un objeto, contiene widgets (textbox) que son objetos y pueden recibir como mensaje que el controlsource sea una variable o un campo (tabla, cursor, etc.)

Pasar un cursor a través de las capas no lo veo como una violación a la funcionalidad de cada capa.

No aprovechar esa posibilidad es no usar VFP.

Saludos: Miguel, La Pampa (RA)

Larga Vida y Prosperidad

Que la Fuerza los acompañe, los cursores vienen marchando

[mapner]

Ahí está el punto, separación en capas es un patrón OOP y a la vez VFP no es una plataforma pura OOP sino un hibrido con una larga historia de retro compatibilidades, entre ellas el manejo de cursores locales y tablas DBF.

VFP es "cursor dependiente", por ejemplo el componente Grilla sin el concepto cursor no funciona, no se puede hacer hacer andar una grilla con un Array o una clase Collection...

Donde si o si la separación de capas es rigurosa y la visibilidad de cursores locales no existe es en la separación de capas físicas... y la separación de capas lógicas debería seguir el mismo concepto por si el día de mañana se quiere distribuir los componentes fuera de un EXE monolítico en el cliente.... Saludos.

[Carlos Miguel FARIAS]

Tus conceptos son correctos, pero no te van a modificar el fox para ello.

Como funciona el modelo de tres capas en entornos como .NET, Pascal, C++, Java?

No usan cursores?

Python tomo un cursor en la capa que sea y lo paso por parámetro, o por propiedad de la clase o por variable global.

Es más, paso una capa como parámetro y luego cualquiera de las otras capas desde adentro le pasan mensajes a la capa definida afuera pero la referencia internamente y si la capa tiene capacidad de iterador, con un simple FOR contra la instancia, me devuelve fila  a fila.

Saludos: Miguel

[mapner]

De hecho, C++, Pascal, .NET, JAVA, etc... no usan cursores... usan estructuras de lenguaje como List o HashMap o Arrays o etc... o sea, elementos que pueden ser  privados a la clase y se pasan valor o referencia.. en lenguajes más "soft" (PHP, Python, Ruby que no son Strong Typed ) se usan "diccionarios" o sea, arrays de asocianes CLAVE-VALOR... el concepto de cursor sin duda está muy bueno y es un invento xBase... bastante previo al furor OOP...

El tema es cuando la capa a pasar está en un servidor remoto y no en forma local, para es pasaje entre capas físicas se usa "serialización / deserialización" que es convertir la estructura de datos interna a un soporte de transporte (JSON, XML, Texto plano, etc...)   en entornos SOAP, RESTful, etc...

O sea, VFP es lo que es, con todo lo bueno y todo lo mejorable que tiene, pero su diseño es un cúmulo de compatibilidades para atrás que lo hacen un híbrido... bastante útil por cierto... Saludos 

[Antonio Meza]

Mapner, si te fijas tu hablas de cosas mas complejas que un 90% de los que programamos en VFP no vamos a usar y hay quienes no tienen la mas mínima idea de lo que comentas.

Ahora a estas alturas diseñar un sistema en VFP con capas separadas en servidores COM pues no se quien haría eso y mas con DBF. con un servidor de base de datos eliminas fácilmente toda esa complejidad

Por eso soy muy claro en mi recomendación "Si vas a programas en VFP" o "solo si vas a usar VFP", porque se claramente como deben funcionar las capas y su separación, eso no se discute, y veo que Miguel comparte el tema de aprovechar los Cursores, porque desperdiciar toda esa capacidad solo por imitar otros lenguajes? si al final estas programando en VFP.

Es decir aprender a programar en Capas es una cosa, y aplicar ese conocimiento en VFP y le añades los Cursores desde mi punto de vista es un PLUS!!!!, cuando vayas a otro lenguaje sabes que eso que haces con los cursores no lo vas a tener, pero sabes que en VFP lo tienes y no usarlo a mi en lo personal me parece hasta tonto jajajajajajaj

P.D.

Desde que programo en capas y veo a los cursores como un objeto, NUNCA he tendido la necesidad de pasar un Cursor como parámetro.

saludos

Antonio Meza

[mapner]

Antonio, sos claro en tus recomendaciones como yo en las mías... Reitero, el concepto de cursor es un invento xBase previo a OOP el cual es muy útil en el entorno para el cual se creó... pero existen otras cosas... Así como dices que hay que aprovechar lo que tiene el VFP yo también digo que se puede aprovechar lo que te da tu S.O. y de hecho con Windows y VFP se pueden hacer objetos distribuidos... Por algo en VFP hicieron conversiones desde y hacia XML la posibilidad de hacer servidores SOAP... se apuntaba a eso antes que MS descartara al zorro...  saludos

[Antonio Meza]

y tu crees que los que a penas están dejando los DBF y los que apenas están aprendiendo capas vayan a aplicar o usar servidores SOAP? u objetos distribuidos? o vayan a compilar DLL en vfp? 

Si pueden consumir un XML, JSON, lo convierten a cursor lo procesan en VFP y lo retornan en XML o JSON, pero para que sacrificar esa ventaja de procesarlo internamente en VFP como un Cursor a usarlos como array o propiedades de un objeto.

En tu caso que ya tienes tus DLL distribuidas seria muy tonto cambiar esa complejidad a reutilizar los cursores, pero para los que apenas empiezan seria muy tonto no aprovechar los cursores y añadir complejidad que no es fácil de digerir al usar DLL, etc.

No se si me explico!!! no estamos en el auge de VFP, como para hacer las cosas perfectamente bien como han explicado ustedes, o sea el tema no es engañar o mentir, es simplemente ser realistas, tener claro como funcionan las capas y combinar ambos mundos en VFP solo en VFP y únicamente para VFP con los cursores. si realmente quiero hacer algo distribuido, DLL, capas lógicas y físicas, la verdad usaría mil veces otro lenguaje pues los cursores ya no son necesarios para este aprovechamiento y por lo tanto ni existen jajajajaja

saludos

Antonio Meza

[Fernando D. Bozzo]

Hola Antonio:

Una cosa es dar opiniones basadas en la propia expereincia, y otra muy distinta es usar la propia experiencia como única experiencia válida o como la más acertada.

Creo que te equivocás bastante sobre algunas de las cosas que estás diciendo respecto a lo que cada uno puede pensar usar --nuevo o no en VFP-- y estás asumiendo demasiadas cosas que abarcan mucho más de lo que puedas haber visto.

A veces es mejor dejar hueco para otras experiencias, otras voces y otras formas de uso, ya que no se puede juzgar o filtrar todo por la propia experiencia solamente, y estás cayendo un poco en eso, lo que es una gran equivocación.

Puedo asegurarte que conozco más de una aplicación en VFP hecha en capas donde los cursores se usan solamente para la capa visual y "no se comparten" con las demás capas, aún pudiendo, simplemente porque se quizo desde un principio mantener esa separación, y gracias a la cual luego se pudo reemplazar partes de los accesos a datos locales por accesos a Oracle, sin tener que cambiar la interfaz. Y estos no son casos donde "no se haya usado la potencia de los cursores de VFP", sino solamente una de tantas formas de hacerlo que no implican usar todo lo de VFP en cualquier caso o situación por el sólo hecho de que técnicamente se pueda.

Y para aprovechar la programación en capas tampoco es necesario hacer DLLs o usar SOAP obligatoriamente. Simplemente hay muchas combinaciones posibles, y ninguna es siempre la mejor. Eso solamente depende de cada aplicación, de cada caso de uso y de cada situación y negocio.

Esto último puede interpretarse de varias formas:

"no estamos en el auge de VFP, como para hacer las cosas perfectamente bien como han explicado ustedes, o sea el tema no es engañar o mentir, es simplemente ser realistas, tener claro como funcionan las capas y combinar ambos mundos en VFP solo en VFP y únicamente para VFP con los cursores. si realmente quiero hacer algo distribuido, DLL, capas lógicas y físicas, la verdad usaría mil veces otro lenguaje pues los cursores ya no son necesarios para este aprovechamiento y por lo tanto ni existen jajajajaja"

Veamos:

"no estamos en el auge de VFP, como para hacer las cosas perfectamente bien como han explicado ustedes"

> ¿O sea que según tu criterio, el hecho de que VFP no esté en auge implica que no haya motivo para hacer las cosas bien o lo mejor posible? => Eso depende de qué tan buen desarrollador quiera ser cada uno, e intentar hacer las cosas lo mejor posible suele ser un objetivo independiente del lenguaje que se use.

"el tema no es engañar o mentir, es simplemente ser realistas"

> Creo que es un poco fuerte decir que, salvo vos, los demás están mintiendo o no siendo realistas => Como te digo, no está bien filtrar todo por la propia experiencia porque hay una fina línea con la arrogancia

"tener claro como funcionan las capas y combinar ambos mundos en VFP solo en VFP y únicamente para VFP con los cursores"

> Nuevamente, aunque no sea tu intención, estás invalidando a cualquiera que no comparta esto, como la única verdad

"si realmente quiero hacer algo distribuido, DLL, capas lógicas y físicas, la verdad usaría mil veces otro lenguaje pues los cursores ya no son necesarios para este aprovechamiento y por lo tanto ni existen jajajajaja"

> Lamentablement esto demuestra un poco de desconocimiento de algunos otros lenguajes que tienen mecanismos similares a los cursores de VFP (aunque no se llamen cursores)no hay

Antonio, con el mejor de los ánimos, no hay que creer que uno mismo tiene "la verdad" en un tema, por mucho que lo conozca. A veces es necesario tener un poco de humildad, y saber que siempre se puede aprender algo nuevo, incluso de lo que cree que más conoce.

Saludos!

[Antonio Meza]

Maestro Fernando con todo el respeto y admiración que usted me merece le comento que siempre pero SIEMPRE lo he dicho y lo repito hasta el cansancio y es lo siguiente

NUNCA de los NUNCA diré que lo que digo es y debe ser tomado como la VERDAD o así deba ser!!! e incluso soy enemigo de los que hacen eso y lo he hecho notar y hasta cometer el error de casi casi condenar y señalar jajajaja

Siempre antepongo las palabras como "en mi experiencia, lo que me ha funcionado, lo que uso, les recomiendo, etc" insisto NUNCA daré por hecho algo que no tengo la base!!!! y aun teniendo la base si alguien me corrige no soy de los que me molestos si no por el contrario se los agradezco y cambio.

Incluso he dicho en este temas reiteradas veces que en la forma que lo han explicado usted y las demás personas es la forma CORRECTA e incluso dije que en eso no hay discusión no se si leyó eso antes?!!!! y si leyó mi articulo también dice claramente que es mi simple opinión, y en la parte final del mismo también dice claramente que cualquier corrección, error, etc es bien recibido pues lo que yo digo NUNCA lleva el tono como VERDAD!!! 

Y de antemano le agradezco las anotaciones que me ha hecho y como siempre hago las tomare muy encenta, pero si debo reiterarle e insistir que la forma que entendió mis palabras no son las correcta, Y bueno solo como comentario he usado otros lenguajes y el termino como tal "cursor" no se maneja tan literal, En PHP se puede obtener un RecordSet que viene siendo un cursor, pero insisto la forma en que me exprese o los términos que use no fueron los correctos pero eso no es problema puedo fácilmente aclarar para que conste en el Acta que soy congruente en lo que siempre digo jejejejeje

Es como la vez pasada que use ID compuesto jajaajj 

saludos

Antonio Meza

[Newbie]

Antonio el tema, es que por más de que te deshagas en excusas o perdones, la verdad es simple, enfocas las cosas (creo que no te das cuenta, por que imagino que no lo haces a propósito) como si fueras el único dueño y poseedor de la verdad y lo correcto, te lo digo por que he leído bastantes de tus mensajes, y apoyo totalmente lo que dice BOZZO, muchas veces quise decírtelo, pero me da pereza entrar en debates fútiles.!!.

[Antonio Meza]

Entonces te pasa como al Secretario de Educación de México que solo sabe LER!!! y no LEER!!! jajajajajajajaj es broma!!!

Si les el ultimo tema es posible que entiendas lo que igual entendió el Maestro Fernando, pero si lees todas mis intervenciones veras que desde un principio dije y de nuevo repito que "en la forma que ellos lo dicen de las capas es la correcta no hay duda en eso" e incluso dije que eso no esta a discusión, no entiendo porque al puntualizar en un tema resulta que las cosas que digo ahora son o se entienden como verdad absoluta?? o sea que no soy una persona congruente? jejejeje

P.D. Para que quede asentado en el Acta, reitero todo lo comentado anteriormente es propio de mi experiencia, lo explico y detallo para el que le interese conocer mi experiencia, y por otro lado también para que quede asentado en el Acta, que en la forma que lo explica el Maestro Fernando, Victor y Carlos es la forma correcta como se deben manejar las capas, y aun mas para que quede asentado en el acta repito y reitero que desde un principio no cuestiono ni estoy cuestionando la forma correcta explicada por los compañeros, simplemente expuse mi experiencia mía de mi jajajajaja digo para que se entienda y quede claro y no haya duda e incluso es algo alterno a las capas!!!!

saludos

Antonio Meza

[Carlos Miguel FARIAS]

Bueno, no discutamos tanto desde lo extremos (con el perdón del colega Extremo).

Coincidamos en que lo mejor que se con Capas es la Mujer Maravilla.

Acá hay que ser realistas. VFP es una herramienta que esta como hace 10 años.

Si hace 10 años lo que tenía servía, se debe usar como estaba y hay que buscar usar lo que da de la mejor manera.

Si alguien nuevo empieza a trabajar con VFP, más que decirle las 101 dálmatas de como se soluciona el problema con vfp, habría que decirle que empezar algo nuevo con esta herramienta, tendría que pensar en trabajar con otra herramienta.

Trabaje mucho tiempo con VFP (desde dBase II) hasta hace pocos años atrás y para mi todo el entorno de desarrollo es casi inmejorable, pero no me parece que si empieza un sistema de cero, o la refactorización es muy grande, habría que pensar en que se encare con otras herramientas.

Y si estás haciendo mantenimiento, ir viendo como convertir parte por parte a otro software.

Saludos: Miguel

[acmc]

Pues despues de leer tantos argumentos de tan buenos exponentes, uno se enriquece con su conocimiento, es lo que me encanta de todo esto!!

[Fernando D. Bozzo]

Hola Carton:

Para continuar con esto, te dejo otra variante.

Ejemplo 2: Usando cursores en la capa visual

Como comenté anteriormente, el uso de cursores también es posible en la programación en capas, aunque con la única limitación de que no se pueden compartir fuera de las mismas.

En este caso, si tuvieras que usar un grid para poder mostrar varios registros (de 10 a 50 máximo), necesitarías poder rellenar ese cursor con información procedente de un array, un XML, un JSON, etc.

Si bien puede haber dudas respecto de la velocidad de hacer algo así, puedo asegurarte que si se implementa bien puede ser muy rápido (pero nunca como el acceso directo a una tabla con todos los registros)
Igualmente el típico grid que muestra toda la tabla, es una práctica que fue común hasta los 90 (en xBase y similares), pero que luego dejó de usarse principalmente por cuestiones de rendimiento y escalabilidad en entornos de red.

El tipo de uso que podés hacer con los cursores, en cuanto al funcionamiento de presentación, sería similar al GMail, donde por defecto te muestra entre 5 y 50 elementos por vez (configurable, por defecto 10), y luego te va paginando cada N registros que hayas elegido mostrar por vez. Por eso vas a ver varias consultas en los foros sobre "consultas paginadas", "consultas progresivas" o similares. Hacer este tipo de consulta paginada no es del todo sencillo, pero hay distintas formas de hacerlo.

Principalmente lo que implica esto es un cambio de mentalidad (muy arraigada en xBase!) respecto de viejas costumbres de "mostrarlo todo" y que el usuario navegue por todos los datos a una mentalidad donde para comenzar al usuario se le presenta una vista pre-filtrada donde puede cambiar los filtros o el ordenamiento y donde principalmente el usuario debe tener cierta idea de lo que quiere buscar o ver y se le presenta un subgrupo de datos. Si quiere ver todo va a poder, pero ya no como se hacía antes. Y pensándolo bien, realmente eso ya no tiene mucho sentido, sobre todo cuando la cantidad de información que se maneja cada vez es mayor.

Una de las técnicas que se puede usar es mostrar la mínima información necesaria, en contraste a la antigua (y mala) práctica de mostrar absolutamente todos los campos de la tabla "para que el usuario elija" lo que le interesa.
Esto requiere más diseño, ya que se muestran en general los campos más importantes o significativos, y los demás se puede mostrar en una ventana de detalle (por ejemplo, la ventana de edición del registro u otra)

Respecto de la edición en sí, no suele usarse el grid para editar, sino que se suele usar una pantalla de edición, pero si se quiere puede editarse el grid, usando el bufffering de registro o tabla para detectar qué campos de qué registros se modifican y asú luego poder preparar un envío de datos (array, XML, JSON, etc) al negocio para que lo pase a la capa de datos (BDD externa)

Los cursores a veces también pueden ser útiles en la capa de negocio, para procesos intermedios (recordar que no se comparten entre capas), aunque en general se suelen usar variables, arrays y objetos.

Resumiendo:

Como ves, realmente se puede usar todo lo que permite el lenguaje, pero con las restricciones propias de un diseño en capas que es justamente lo que permite poder reemplazarlas por separado sin tener que rediseñar el resto.
Lo importante es pensar en un diseño que sea eficiente, que tenga en cuenta a las partes y cómo se comunican, que minimice las conversiones de datos y que respete las separaciones de las capas.

Para el tema de las clases de datos, negocio y visual, suelen usarse librerías distintas, de modo de poder enfocar el mantenimiento posterior de forma más específica.
Te recomiendo enfocar cada funcionalidad en cosas básicas, funcionalidades mínimimas que puedan ser controladas por una funcionalidad principal (esto se llama orquestación).

Te dejo un pequeño ejemplo de un método orquestador (puede haber muchos) para que te des una idea:

PROCEDURE GuardarDatos( toDatos, toException as Exception ) as Boolean
   toException = NULL

   TRY
      WITH THIS
         .ValidarDatos( toDatos )          && Si hay algún error, ValidarDatos puede relanzarlo con THROW
         .oDatos.GuardarDatos( toDatos )   && Si hay algún error, GuardarDatos (capa datos) puede relanzarlo con THROW
      ENDWITH

   CATCH TO toException
      (control de errores)
   ENDTRY

   RETURN ISNULL(toException)
ENDPROC

El método orquestador realmente no hace nada por si mismo, sino que solamente llama a otros métodos que son los que realmente hacen las tareas.
Por eso es tan importante que cada método haga una funcionalidad mínima, así se pueden reutilizar por otros métodos orquestadores.

Puedo decirte que una vez que comenzás a trabajar de esta forma y comenzás a encapsular funcionalidades, comenzás a ver algunas cosas más claras, y cuando te encontrás con un método que hace más de lo que debiera, enseguida pensás en subdividirlo en partes más chicas que hagan menos cosas. Este proceso se llama "refactorización".

Seguramente algunas de las cosas que comento ya las conocés, pero por las dudas prefiero dejarlo claro por si no fuera el caso o para otros que no lo tengan claro.

Espero que te haya servido :D

Saludos!

[Carton Jeston]

Sobre Antonio alias "foxyDB", llevo unos años leyendo por aqui y nunca dice nada con mala intencion, excepto cuando toca el tema religioso y enciende algunas hogueras. Igual esa actitud puede resultar molesta a veces, mas me molestaria que no dijera nada o que actuase de forma diferente a como es. Tambien entiendo el planteamiento de aprovechar los cursores y las bondandes de fox en un exe monolitico, a sabiendas de sus limites simplemente porque tiene la comodidad de hacer ciertas cosas y tener mejor estructurada la aplicacion para su mantenimiento. Si conoces que problemas o limitaciones te encontraras en el futuro, creo que es valido.

Otra cosa es que algunos compañeros piensen que no sabes OPP, programacion estructurada o si realmente sabes programar algo y para que lo vas a usar. Cuando decides repasar todo y aprender de nuevo, no puedes permitirte pensar que lo sabes casi todo, sino que preguntas como lo hacen y porque. Como no hay dos preguntas iguales ni una sola forma de hacer las cosas, a veces puede ser confuso, por no hablar de que en vez de responder a una pregunta concreta, nos vamos por las ramas :D

Para mi todas las opiniones tienen valor, cuando se debate incluso acaloradamente como ahora, resultando un hilo de lo mas interesante. Animo a que siga siendo asi.

Mpulla, respecto a Xojo solo me interesa windows y sobre todo la posibilidad de aplicacion en web. ¿has probado algo al respecto? Y te doy la razon en todo lo que dices y tus recomendaciones buenas, Postgresql es la que usan en modo nativo y posiblemente este hecho hara que haga lo mismo en fox, a pesar de mi preferencia inicial con firebird. Tambien esta la posibilidad de comprar un plugin que ya existe para esto, pero ya sabes el mercado paralelo de pagar por todo y al final te sale carisimo si no te lo haces tu mismo. En tu empresa tendrias que ver la posibilidad de actualizar esos XP, mas que nada por poder usar versiones mas modernas de xojo o llegara un momento y tendras un producto obsoleto :D

Fernando, como siempre aportando todo lo que puede hasta donde te llega la bateria. Ya he empezado a trabajar con el ejemplo con un formulario y una tabla simple y sin duda surgiran mas dudas. Ya tenia hecho algo a partir de tus articulos del blog, pero mejor sigo con este ejemplo.

Con todo lo que se ha dicho, esta claro que para programar con capas es fundamental la separacion y la forma de comunicarse, sobre todo si estas pensando el dia de mañana crear una capa visual desde web en otro lenguaje.

A ver si puedo extenderme un poco mas tarde... Gracias a todos

[mapner]

Carlos Jeston, me permito transcribir un párrafo del escritor Ernesto Sábato (libro Uno y el universo), sobre el entendimiento:

"Alguien me pide una explicación de la teoría de Einstein. Con mucho entusiasmo, le hablo de tensores y geodésicas tetradimensionales.

—No he entendido una sola palabra —me dice, estupefacto.

Reflexiono unos instantes y luego, con menos entusiasmo, le doy una explicación menos técnica, conservando algunas geodésicas, pero haciendo intervenir aviadores y disparos de revólver.

—Ya entiendo casi todo —me dice mi amigo, con bastante alegría— Pero hay algo que todavía no entiendo: esas geodésicas, esas coordenadas...

Deprimido, me sumo en una larga concentración mental y termino por abandonar para siempre las geodésicas y las coordenadas; con verdadera ferocidad, me dedico exclusivamente a aviadores que fuman mientras viajan con la velocidad de la luz, jefes de estación que disparan un revólver con la mano derecha y verifican tiempos con un cronómetro que tienen en la mano izquierda, trenes y campanas.

—¡Ahora sí, ahora entiendo la relatividad! —exclama mi amigo con alegría.

—Sí —le respondo amargamente—, pero ahora no es más la relatividad."

http://literatops.blogspot.com.ar/2008/09/en-uno-y-el-universo-de-ernesto-sbato.html

Si hablamos de programación en capas, posiblemente estemos hablando de OOP, o por lo menos un enfoque que se le aproxima bastante en cuanto porciones de código con responsabilidades bien definidas, encapsulamiento (u ocultamiento) de sus lógicas internas y su interrelación por medio de interfaces bien establecidas. Pero si a la idea original, le comenzamos a hacer ciertas "licencias adaptativas" a la comodidad del entorno, llega un momento que deja de ser programación en capas, y pasa a ser otra cosa.

Saludos

(sepan disculpar el arrebato literario... hoy es viernes...)

[Carton Jeston]

He entendido lo que quieres decir, puede llegar a ser "espaguetti en capas" si te descuidas. Aun asi entiendo los riesgos y que otros compañeros sopesen ambas cosas y elijan un camino intermedio pero eso lo puede hacer un programador que ya domine ese tema. En mi caso que no programo en capas, tengo que hacerlo si o si del modo que me indican y cuando lo tenga claro ya vere como optimizar para ahorrar tiempo. Aunque bien pensando el objetivo de este hilo es optimizar un desarrollo desde el principio, viendo varios puntos de vista, ya que en el blog de Fernando es donde estudio esta metodologia.

Sobre el entendimiento un Viernes tarde, te dire un caso real, cuando daba clases y mis alumnos ponian cara rara cuando les pedia que miraran el monitor. Cuando les decia que miraran la pantalla entonces asentian y lo comprendian a la primera hasta que empece a decir pantalla. Y todo eso con las risas de mis compañeros del profesorado, que años mas tarde con la salida de las pantallas planas, se les quedo la cara de poker cuando les recorde que yo tenia razon. Eran pantallas!!! :D

Moraleja: Para que haya un buen entendimiento, es necesaria una buena comunicacion y no importa el lenguaje empleado mientras se comprenda. :D

[Carton Jeston]

Sobre el tema de recomendar si se hace un desarrollo nuevo, dejar foxpro y recomendar nuevas herramientas tambien tiene su logica.

Por otro lado tambien pense que a veces por el camino mas largo se llega antes y cuando sabes lo que quieres todo va mas rapido. Tengo una aplicacion que necesita mejoras y hasta ahora solo he hecho parches que han funcionado bien pero tiene un problema estructural muy grande. Asi que tengo en mente rehacerla aprovechando lo mas posible lo que tengo y en un lenguaje natural que es para mi el xbase.

La segunda fase, con una aplicacion diseñada correctamente, se lo que necesito buscar en otro lenguaje para hacer lo mismo y "solo" hay que traducir ese monton de codigo y no pelearme con las malas practicas, bases de datos y demas problemas que arrastra desde hace tiempo.

Yo solo se que aplicando una mejoras a la actual, el tiempo de mantenimiento se ha reducido y he ganado mas tiempo libre para dedicar a recliclarme. No quiero imaginar el que tendre cuando termine el primer paso :D

Y no quito la razon a quien dice que estamos en una via muerta y ese no es el problema, sino sentarse a esperar a que la via termine ;-)