Hola, Ricardo.

>Hace unos días planteaba la inquietud de re-progrmar un sistema FoxPro 2.6 a VFP client/server y Plinio Fermin nos daba la sugerencia de crearnos nuestro propio FrameWork.
>
>Luego de varios dias de discución optamos por esta opción.
>Estamos creando nuestro propio FrameWork client/server basado en vistas remotas parametrizadas y SQL Pass Through (de uso interno y sin fines comerciales).
>Tomamos como base el ejemplo de Tastrade que trae VFP y lo modificamos a origenes de datos remotos ademas de quitarle metodos innecesarios y agregarle los propios.

Coincido con Alex en recomendarte no ponerte a desarrollarlo. Menos aún si tienen tantas dudas básicas de arquitectura. Ten en cuenta que desde que comiences hasta que puedas usar el framework pueden pasar muchos meses, sino un año o más.

>Un tema interesante que queria cometarles es que no estamos usamos la clase CursorAdapter ya que vimos en principio varios obstaculos:

>- No soporta en forma nativa clausulas WHERE.
¿Quién te dijo eso? Por supuesto que soporta WHERE.

>- Usar la propiedad .SelectCmd nos parece muy pesada y larga, ademas soporta hasta 255 caracteres y mucho 'coding'.
No entiendo porque escribir un Select aquí es más pesado que en una vista. El límite de 255 caracteres es un problema del Builder, no del CursorAdapter, y por cierto está arreglado en VFP 9.

>- El binding es mucho mas práctico con el DataEnvirnoment y vistas remotas.
El binding usando DE con CursorAdapters es idéntico a usar vistas. Por otro lado, si vas a usar DE ten en cuenta que no estás separando la capa de datos, sino que sigues en una arquitectura monolítica.

>- No pudimos usar comandos nativos de SQL
No se a qué te refieres. CursorAdapter permite un nivel de control absoluto de las sentencias SQL.

>- Nos parecio que tenemos que escribir mucho mas codigo usando CursorAdapter con las propiedades .SelectCmd, .InsertCmd y .DeleteCmd por cada tabla que vamos a usar en un form que simplemente arrastar al DataEnvirnoment la vista remota.
Nuevamente, lo que tienes que escribir en CA es el mismo select que lleva la vista. La diferencia parece ser el editor de vistas, por lo que veo. En CA, marcando las propiedades correctas (de la misma forma que en las vistas) para las PK, campos actualizables, etc, no necesitas escribir ni InsertCmd ni SelectCmd. La gracia es que están ahí para los casos en que NO pueden deducirse estas sentencias desde el Select; algo que no puedes hacer con las vistas.

>- Con un método de conectividad lo suficientemente inteligente nos podemos aproximar bastante a una plataforma n-tier y alejarnos de la programación monolitica (estamos trabajando en eso).
Pues si usas DataEnvironment vas en sentido contrario.

>Hay un articulo de Les Pinter muy bueno en base a trabajar en 3 capas que lo usamos como referencia:
>http://www.mug.org.ar/FoxProGufa/ArticFox/210.aspx
>Y hay una discución sobre CursorAdapter muy interesente en Wikis:
>http://fox.wikis.com/wc.dll?Wiki~CursorAdapterOrNot~VFP

En ambos casos, es importante extraer lo bueno y lo malo. Coincido en parte con algunos de los argumentos contra el CA, pero la mayoría se resuelven extendiéndolo, cosa que también debe hacerse con otro mecanismos de acceso a datos.

>Mucho de estos problemas son fruto de nuestra ignorancia de no conocer la clase a fondo. Pero nos parecio interesante discutirlo y saber si alguien esta trabajando en algún proyecto similar y se topó con el dilema de usar Vistas Remotas, CursorAdapter o S.P.T. y cuales fueron sus razones para usar una u otra.

Uno de los principales puntos a favor de CursorAdpater es la flexibilidad para usar ODBC, ADO, datos nativos, etc, manteniendo la misma interfaz (de allí el nombre Adapter, que remite a ese patrón de diseño).

El tema es realmente complejo y depende mucho del tipo de uso que quieras darle. Por todo esto es que en general desaconsejo ponerse a inventar la rueda nuevamente, y lo digo con conocimiento de causa: ya llevo varios frameworks desarrollados y siempre es una tarea ardua, que exige estudiar mucho y dedicarle enorme cantidad de tiempo. Si vas a hacerlo para uso externo y realmente te pagan por ello, adelante, pero sino, lo usual es quedar con algo a la mitad, con problemas estructurales y bajo nivel de prueba (una sola instalación o dos) que debes poner en marcha de todas maneras porque el tiempo se acaba. No suele ser un buen prospecto.

Saludos,