Dudas sobre la programación n-capas.

Hola Llorenç, te respondo entre líneas.


- 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?

En primer lugar creo que te ha ocurrido como a mí me ocurrió en un
principio, y es que, los artículos que hay por la web y en diferentes
portales sobre la programación en n-Capas, son muy buenos y muy técnicos,
a la par que muy utilizables como guías paso a paso, pero pecan de no
saber dar a entender al lector la finalidad de cada capa de forma clara y
concisa.
El hecho de que se separen las capas de datos, negocio y cliente, no
quiere decir que esté prohibido utilizar cursores en cada una de ellas. Me
explico.
Yo utilizo una capa de acceso a datos en la cual utilizo CursorAdapter
para acceder a los datos.
En mi capa de negocio, recojo la solicitud de la capa de cliente y la
traspongo a la capa de datos, es decir, en lo concerniente a la obtención
de los datos, tan sólo hace de puente en la solicitud, ya que si omito
este paso, estaría rompiendo las reglas concernientes a que una capa de
cliente no debe acceder directamente a la de datos. Pues bien, mi capa de
datos me devuelve un XML con la información que preciso, pasando por la
capa de negocio, que hace de puente de esta información.
Cuando yo obtengo los datos en mi capa de cliente, lo primero que hago es
extraer esa información y ubicarla en un cursor VFP, ya que es la forma
más rápida y cómoda de tratar los datos en la capa de cliente. De este
modo trabajo en la capa cliente con cursores VFP locales. Cuando debo
actualizar datos, hago el paso inverso, es decir, convierto la información
de mis cursores en XML, y se lo paso a la capa de negocio, que a su vez la
pasa a la de datos.

- ¿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.
¿Qué opinan al respecto? ¿Lo ven viable?

Eso es precisamente la tecnología multi-capa o de automatización a través
de componentes.

- 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?

En el caso de usar BD nativa de VFP, puedes hacerlo con un componente, y
en el caso de utilizar BD Servidoras puedes utilizar procedimientos
almacenados, aunque ahí no puedo opinar porque no las he necesitado aún.

- 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.

Prefiero la opción de compatibilidad.

- 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?

Ten en cuenta que si cambias de base de datos, la capa de acceso a datos
cambiará, por lo tanto no debe preocuparte eso tanto. Tan sólo explota lo
mejor del motor que utilices.

Salu2


Nacho Amorós
<a href="mailto:infomartin&#64;terra.es">infomartin&#64;terra.es</a>

-
PortalFox :: Nada corre como un zorr
http://www.portalfox.co

PortalFox - NNTP Forum Gatewa

http://www.microsoft.com/spanish/ms.../art20.asp




-
PortalFox :: Nada corre como un zorr
http://www.portalfox.co

PortalFox - NNTP Forum Gatewa

Me llamó la atención como despues de investigar este tema durante meses y
ponerlo en paráctica en una aplicación en tres capas, hemos llegado casi a
la misma conclusión y manera de tratar los datos que el compañero Nacho.

sobre todo en lo que respecta a la división de tareas de las distintas capas
y en cuanto a como trasladar y manipular los datos entre capas. Esto me
alegra ya que significa que no estuve tan errado en los conceptos.

Ademas quisiera acalrar la importancia de validar las reglas comerciales en
la capa intermedia.

Una de las mejores cosas de este sistema es que podemos seguri utilizando
los cursores de nuestro querido VFP como lo veniamos haciendo hasta ahora
con la ventaja adicional de darle claridad a la aplicación ya que cada capa
tiene sus responsabilidades y permite tener una visión mas clara en sistemas
grandes.



Saludos




"Nacho Amorós" wrote in message
news:

Hola Llorenç, te respondo entre líneas.


- 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?

En primer lugar creo que te ha ocurrido como a mí me ocurrió en un
principio, y es que, los artículos que hay por la web y en diferentes
portales sobre la programación en n-Capas, son muy buenos y muy técnicos,
a la par que muy utilizables como guías paso a paso, pero pecan de no
saber dar a entender al lector la finalidad de cada capa de forma clara y
concisa.
El hecho de que se separen las capas de datos, negocio y cliente, no
quiere decir que esté prohibido utilizar cursores en cada una de ellas. Me
explico.
Yo utilizo una capa de acceso a datos en la cual utilizo CursorAdapter
para acceder a los datos.
En mi capa de negocio, recojo la solicitud de la capa de cliente y la
traspongo a la capa de datos, es decir, en lo concerniente a la obtención
de los datos, tan sólo hace de puente en la solicitud, ya que si omito
este paso, estaría rompiendo las reglas concernientes a que una capa de
cliente no debe acceder directamente a la de datos. Pues bien, mi capa de
datos me devuelve un XML con la información que preciso, pasando por la
capa de negocio, que hace de puente de esta información.
Cuando yo obtengo los datos en mi capa de cliente, lo primero que hago es
extraer esa información y ubicarla en un cursor VFP, ya que es la forma
más rápida y cómoda de tratar los datos en la capa de cliente. De este
modo trabajo en la capa cliente con cursores VFP locales. Cuando debo
actualizar datos, hago el paso inverso, es decir, convierto la información
de mis cursores en XML, y se lo paso a la capa de negocio, que a su vez la
pasa a la de datos.

- ¿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.

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

Eso es precisamente la tecnología multi-capa o de automatización a través
de componentes.

- 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?

En el caso de usar BD nativa de VFP, puedes hacerlo con un componente, y
en el caso de utilizar BD Servidoras puedes utilizar procedimientos
almacenados, aunque ahí no puedo opinar porque no las he necesitado aún.

- 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.

Prefiero la opción de compatibilidad.

- 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?

Ten en cuenta que si cambias de base de datos, la capa de acceso a datos
cambiará, por lo tanto no debe preocuparte eso tanto. Tan sólo explota lo
mejor del motor que utilices.

Salu2


Nacho Amorós
<a href="mailto:infomartin&#64;terra.es">infomartin&#64;terra.es</a>


PortalFox :: Nada corre como un zorro
http://www.portalfox.com

PortalFox - NNTP Forum Gateway

Gracias por aclararme todas mis dudas. Sólo una cosa más, relacionada con la
última pregunta:

- 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?

Ten en cuenta que si cambias de base de datos, la capa de acceso a datos
cambiará, por lo tanto no debe preocuparte eso tanto. Tan sólo explota lo
mejor del motor que utilices.

Si utilizara el ANSI SQL podría cambiar de base de datos sin tener que tocar
nada de la la capa de acceso a datos. Si, por ejemplo, la cadena de conexión
con la base de datos se encontrara como constante en una include, bastaría
con modificar el valor para la constante y recompilar el componente.



"Nacho Amorós" escribió en el mensaje
news:

Hola Llorenç, te respondo entre líneas.


- 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?

En primer lugar creo que te ha ocurrido como a mí me ocurrió en un
principio, y es que, los artículos que hay por la web y en diferentes
portales sobre la programación en n-Capas, son muy buenos y muy técnicos,
a la par que muy utilizables como guías paso a paso, pero pecan de no
saber dar a entender al lector la finalidad de cada capa de forma clara y
concisa.
El hecho de que se separen las capas de datos, negocio y cliente, no
quiere decir que esté prohibido utilizar cursores en cada una de ellas. Me
explico.
Yo utilizo una capa de acceso a datos en la cual utilizo CursorAdapter
para acceder a los datos.
En mi capa de negocio, recojo la solicitud de la capa de cliente y la
traspongo a la capa de datos, es decir, en lo concerniente a la obtención
de los datos, tan sólo hace de puente en la solicitud, ya que si omito
este paso, estaría rompiendo las reglas concernientes a que una capa de
cliente no debe acceder directamente a la de datos. Pues bien, mi capa de
datos me devuelve un XML con la información que preciso, pasando por la
capa de negocio, que hace de puente de esta información.
Cuando yo obtengo los datos en mi capa de cliente, lo primero que hago es
extraer esa información y ubicarla en un cursor VFP, ya que es la forma
más rápida y cómoda de tratar los datos en la capa de cliente. De este
modo trabajo en la capa cliente con cursores VFP locales. Cuando debo
actualizar datos, hago el paso inverso, es decir, convierto la información
de mis cursores en XML, y se lo paso a la capa de negocio, que a su vez la
pasa a la de datos.

- ¿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.

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

Eso es precisamente la tecnología multi-capa o de automatización a través
de componentes.

- 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?

En el caso de usar BD nativa de VFP, puedes hacerlo con un componente, y
en el caso de utilizar BD Servidoras puedes utilizar procedimientos
almacenados, aunque ahí no puedo opinar porque no las he necesitado aún.

- 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.

Prefiero la opción de compatibilidad.

- 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?

Ten en cuenta que si cambias de base de datos, la capa de acceso a datos
cambiará, por lo tanto no debe preocuparte eso tanto. Tan sólo explota lo
mejor del motor que utilices.

Salu2


Nacho Amorós
<a href="mailto:infomartin&#64;terra.es">infomartin&#64;terra.es</a>


PortalFox :: Nada corre como un zorro
http://www.portalfox.com

PortalFox - NNTP Forum Gateway

Eso es correcto Llorenç, no obstante me remito a mi primera respuesta:

Explota lo mejor del motor de tu BD. No sacrifiques la potencia a cambio
de una compatibilidad que quizá nunca vayas a cambiar de BD. El hecho de
colocar los procedimientos almacenados en un componente, te ayuda bastante
en el cambio de BD, pero no te recomiento que sacrifiques el SQL, ya que
tampoco hablamos de "grandes cambios" en la capa de datos, y menos
utilizando la nueva clase CursorAdapter.

Salu2


Nacho Amorós
<a href="mailto:infomartin&#64;terra.es">infomartin&#64;terra.es</a>

-
PortalFox :: Nada corre como un zorr
http://www.portalfox.co

PortalFox - NNTP Forum Gatewa