Mi opinión personal es que es mucho mejor y mucho mas barato comprar un Framework comercial. La experiencia de mucha gente dice que tu primer framework propio dejara mucho que desear, debido a la inexperiencia y a la complejidad del tema. Normalmente tu primer intento debiera ser tirado por la borda luego de un tiempo y re-hecho basado en experiencia.

La cantidad de horas de trabajo que hay que meter en un buen framework es enorme. Este es tiempo que no se dedica a un proyecto concreto de clientes, o sea tiempo generalmente no facturable. El costo de un framework comercial, con los miles de horas-hombre que tienen, el debugging hecho por cientos o miles de usuarios en una cantidad enorme de situaciones, hace que nunca lograrás aproximarte al poder, capacidad y flexibilidad de uno de estos. Para que reinventar la rueda? Con solo instalar un framework comercial, pasar un poco de curva de aprendizaje (dado el buen soporte y documentación que casi todos tienen), hace que en poco tiempo tengas un esqueleto de una aplicación profesional.

En mi caso yo uso Visual MaxFrame Professional (VMP2005). No es el único ni se puede decir que sea mejor que otros sino que esta a primer nivel como otros (VFE, MM, etc.)

La cantidad de cosas que te permite hacer y el soporte técnico y la capacidad de Drew Speedie (su arquitecto principal) es de un valor incalculable.

Ver:
http://fox.wikis.com/wc.dll?Wiki~FrameworkFeatureChart
http://fox.wikis.com/wc.dll?Wiki~CategoryFrameworks


Con respecto a vistas, vs. SPT vs CursorAdapter. Es mas que todo una opinión personal.

Yo prefiero SPT porque lo uso desde antes, y CA salió mucho despues de utilizar un framework basado en SPT. CA es bueno y mucho mas OOP pero tiene algunas deficiencias (especialmente en granularidad de creación queries). Asi y todo, yo lo consideraría seriamente.

SPT es muy flexible y con un framework (tuyo o no) que haga de wrapper tienes una herramienta fácil de usar y poderosa. Vistas remotas yo dejaría como última opción. Son mas antiguas, menos flexibles y dependen de un DBC, pero son muy fáciles de usar ya que se usan como tablas o cursores.



>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.
>
>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.
>- Usar la propiedad .SelectCmd nos parece muy pesada y larga, ademas soporta hasta 255 caracteres y mucho 'coding'.
>- El binding es mucho mas práctico con el DataEnvirnoment y vistas remotas.
>- No pudimos usar comandos nativos de 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.
>- 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).
>
>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
>
>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.