Dudas sobre la programación n-capas.

Mis dudas son las siguientes:

- Si queremos trabajar con n-Capas y, por lo tanto, creamos un servidor de
automatización, o dos, con las reglas de negocio y el acceso a datos; este
componente COM debe devolver un recordset y dejar así de utilizar la
potencia y facilidad de programación que nos proporcionan los cursores en
Visual FoxPro?

- ¿Podría pasarle al componente un parámetro para que devolviera un
recordset o un cursor en función de su valor? De esta forma podría
asegurarme de que funcionara tanto desde Visual FoxPro como desde cualquier
otro lenguaje y hacer más fácil y potente la programación desde el primero.

- También deduzco que con ese tipo de programación si que no tiene ningún
sentido la utilización de vistas remotas. ¿Verdad? Por lo tanto tendré que
actualizar yo los datos mediante instrucciones de paso a través de SQL ¿No?

- Por último, preguntarles si ciertos procedimientos relacionados con las
reglas de negocio es mejor programarlos como procedimientos almacenados en
la base de datos, con el objetivo de conseguir la mayor rapidez de
ejecución; o por el contrario es mejor programarlos en la capa intermedia
para así conseguir mayor portabilidad del código en caso de migrar a un SGBD
distinto.

- Y relacionado con esto último, y ahora sí que acabo: ¿Es recomendable
utilizar el ANSI SQL renunciando así a las peculiaridades de cada sistema
gestor de base de datos y la potencia que ello conlleva?

On Sun, 1 Aug 2004 11:45:45 +0200, "Llorenç" wrote:


>Mis dudas son las siguientes:
>
>- Si queremos trabajar con n-Capas y, por lo tanto, creamos un servidor

>automatización, o dos, con las reglas de negocio y el acceso a datos;

>componente COM debe devolver un recordset y dejar así de utilizar la
>potencia y facilidad de programación que nos proporcionan los cursores en
>Visual FoxPro?

No necesariamente. Puedes pasar XML (práctico si los datos no son
muchos)



>- ¿Podría pasarle al componente un parámetro para que devolviera un
>recordset o un cursor en función de su valor? De esta forma podría
>asegurarme de que funcionara tanto desde Visual FoxPro como desde

>otro lenguaje y hacer más fácil y potente la programación desde el

Parámetro, si. Cursor, no. Un objeto COM no entiende el sistema de
cursor de VFP. Puedes usar XML que es traducible a cualquier lenguaje.



>- También deduzco que con ese tipo de programación si que no tiene ningún
>sentido la utilización de vistas remotas. ¿Verdad? Por lo tanto tendré

>actualizar yo los datos mediante instrucciones de paso a través de SQL

No necesariament. SPT es mas poderoso. Pero puedes usar ADO, o
CursorAdapter por ejemplo. Vistas remotas no tienen mucho sentido en
ese ambiente.


>- Por último, preguntarles si ciertos procedimientos relacionados con las
>reglas de negocio es mejor programarlos como procedimientos almacenados

>la base de datos, con el objetivo de conseguir la mayor rapidez de
>ejecución; o por el contrario es mejor programarlos en la capa intermedia
>para así conseguir mayor portabilidad del código en caso de migrar a un

>distinto.

Como siempre, depende. Como bien dices, la lógica que pones en la capa
de dato sno es portátil. Luego, al mover a otra BD, eso lopierdes. Por
ello, la lógica de negocios (Business Rules) debe ir en la capa del
medio. En la capa de datos, puedes usar SP para acelerar consultas,
poniendo alli lógica de integridad de datos y cosas por el estilo que
tienen sentido en esa capa.


>- Y relacionado con esto último, y ahora sí que acabo: ¿Es recomendable
>utilizar el ANSI SQL renunciando así a las peculiaridades de cada sistema
>gestor de base de datos y la potencia que ello conlleva?

Si. ANSI es mas compatible. Hace la lectura de una sentencia SQL mas
fácil y hace su ejecución y sentido menos ambiguo en ciertos casos.
Por ello, VFP9 va ahora a ser mas compatible con ANSI-92 que antes.

HTH



Alex Feldstein
________________________________
Microsoft Visual FoxPro MVP
Please respond in the public groups so that everybody
can benefit from the exchange.
Favor de responder en los foros públicos asi todos se benefician.
(Address scrambled with ROT-13)

Gracias por aclararme todas mi dudas ;-)

Bueno... sólo me queda una. Sino el objeto COM no devuelve un cursor, no
puedo vincular mis objetos (Textbox, Grids...) a ellos. Tendré que programar
entonces como si lo hiciera con Visual Basic y ADO, por ejemplo? No estoy
perdiendo así practicidad a la hora de programar?

Acabo de leer un artículo muy bueno sobre la programación en n-Capas, y

quedado gratamente sorprendido por la simplicidad y practicidad,

Buenas:

Acabo de leer un artículo muy bueno sobre la programación en n-Capas, y

quedado gratamente sorprendido por la simplicidad y practicidad, sigo sin
tener claras algunas cosas. Hace ya algunos meses que estoy estudiando

llevar a cabo lo más correctamente posible la programación n capas en un
proyecto que empezaré dentro de poco. Es un tema sobre el que he leído

pero sobre el que aún no he trabajado, pues hasta ahora todos mis

se basan en aplicaciones 2 capas (Cliente/Servidor).

Mis dudas son las siguientes:

- Si queremos trabajar con n-Capas y, por lo tanto, creamos un servidor de
automatización, o dos, con las reglas de negocio y el acceso a datos; este
componente COM debe devolver un recordset y dejar así de utilizar la
potencia y facilidad de programación que nos proporcionan los cursores en
Visual FoxPro?

- ¿Podría pasarle al componente un parámetro para que devolviera un
recordset o un cursor en función de su valor? De esta forma podría
asegurarme de que funcionara tanto desde Visual FoxPro como desde

otro lenguaje y hacer más fácil y potente la programación desde el

¿Qué opinan al respecto? ¿Lo ven viable?

- También deduzco que con ese tipo de programación si que no tiene ningún
sentido la utilización de vistas remotas. ¿Verdad? Por lo tanto tendré que
actualizar yo los datos mediante instrucciones de paso a través de SQL

- Por último, preguntarles si ciertos procedimientos relacionados con las
reglas de negocio es mejor programarlos como procedimientos almacenados en
la base de datos, con el objetivo de conseguir la mayor rapidez de
ejecución; o por el contrario es mejor programarlos en la capa intermedia
para así conseguir mayor portabilidad del código en caso de migrar a un

distinto.

- Y relacionado con esto último, y ahora sí que acabo: ¿Es recomendable
utilizar el ANSI SQL renunciando así a las peculiaridades de cada sistema
gestor de base de datos y la potencia que ello conlleva?

Muchas gracias desde ya.

Saludos,

Llorenç