Ayuda modelo de tres capas...

On Fri, 1 Jul 2005 10:13:37 +0200, "Miguel Angel Campos" <SPAMmacampos
ARRUBA .idesarrollaSPAM.com> wrote:

te estaba esperando, sabía que ibas a escribir en este hilo. Y de antemano
se que no llegaremos a ningún sitio por que se tu forma de pensar al
respecto de la arquitectura de 3 capas, pero bueno que le vamos a hacer.

Mi forma de pensar es la generalmente aceptada por los expertos en
bases de datos. De ahí la he sacado.

La demo que me has enseñado es muy bonita, y queda muy bien en las
presentaciones de los Evangelistas de Microsoft para enseñar las nuevas
virtudes de Visual Studio 2005, las cuales sin dudas son muy buenas y es uno
de los mejores entornos de desarrollo que nunca ha exisitido.

Si, aunque casi todo lo que enseña esa demo se puede hacer con Delphi
desde hace 10 años.

Visual Studio 2003 deja mucho que desear en el aspecto de trabajar con
bases de datos, pero Microsoft ha reaccionado a las críticas y está
mejorando mucho las cosas, y lo hace en la línea de "mi forma de
pensar", sobre todo con Comega.

Pero simplemente es eso una demostración de lo que se puede hacer, arastando
y soltando, pero cuando hacemos una aplicación de calle, la cosa cambia.
Esto está muy bonito para hacer un piloto de cara a un cliente, en donde el
rápidamente pueda ver los campos descriptivos de lo que el llama cliente, y
lo que llama pedido; y la aplicación parezca que hace muchas cosas.

O sea, que según tú, lo que hace Microsoft está mal :)

Pero es curioso, me has referenciado una demostración que en la slide del
minuto 2:33, indica que funciona muy bien desde "Web Services, objetos de
negocio... y bases de datos locales" y que esperan que en la versión final
funcione en bases de datos SQL Server remotas o con cualquier cadena de
conexión (esto ultimo no es caracteristico puesto que seguro que terminará
funcionando con SQL directamente). Peo antepone Web Service, y objetos de
negocio a acceso directo a SQL Server, por algo será!.

Pues será por que era más fácil de implementar y acabaron antes, o por
cualquier otra razón irrelevante para nosotros. Lo importante es que
eso va a estar disponible para trabajar con SQL Server, Oracle y
cualquier otro SGBD.

Con respecto a las consultoras y a los tiempos de desarrollo, de eso mejor
ni hablamos, por que cuando te empieze a hablar de herramientas como
CodeSmith, MyGeneration, etc, que reducen el tiempo de desarrollo de una
capa de acceso a datos en un 60%, y facilitan el desarrollo de componentes
de negocio de una forma brutal. Tu diras que se pierde mucho rendimiento,
etc, etc, etc.

Ya, pero lo reducen un 60% después de haberlo aumentado un 1000%, por
ejemplo, por usar una metodología equivocada, ahí está el truco.


Saludos

Hola Alfredo,

"Alfredo Novoa" escribió en el mensaje
news:

On Fri, 1 Jul 2005 10:13:37 +0200, "Miguel Angel Campos" <SPAMmacampos
ARRUBA .idesarrollaSPAM.com> wrote:

te estaba esperando, sabía que ibas a escribir en este hilo. Y de antemano
se que no llegaremos a ningún sitio por que se tu forma de pensar al
respecto de la arquitectura de 3 capas, pero bueno que le vamos a hacer.

Mi forma de pensar es la generalmente aceptada por los expertos en
bases de datos. De ahí la he sacado.

Tu lo has dicho de los expertos en bases de datos, que no tienen por que ser
los expertos en Arquitectura de sistemas, sólo expertos en bases de datos.
Un MCDBA puede conocer mucho de SQL Server pero no tener una correcta visión
de posibles arquitecturas, a diferencia de un MCSD o del futuro MCA. (Estas
certificaciones son ejemplos no es necesario tener una para conocer bien un
producto).

La demo que me has enseñado es muy bonita, y queda muy bien en las
presentaciones de los Evangelistas de Microsoft para enseñar las nuevas
virtudes de Visual Studio 2005, las cuales sin dudas son muy buenas y es
uno
de los mejores entornos de desarrollo que nunca ha exisitido.

Si, aunque casi todo lo que enseña esa demo se puede hacer con Delphi
desde hace 10 años.

Perdona pero Delphi no tiene eso desde hace 10 años, por lo menos en la
versión 3 y 4 no lo tenía al nivel que lo tiene Visual Studio 2005. Me
puedes contar mil y una historias, pero conozco muy bien esas versiones.

Visual Studio 2003 deja mucho que desear en el aspecto de trabajar con
bases de datos, pero Microsoft ha reaccionado a las críticas y está
mejorando mucho las cosas, y lo hace en la línea de "mi forma de
pensar", sobre todo con Comega.

Pero simplemente es eso una demostración de lo que se puede hacer,
arastando
y soltando, pero cuando hacemos una aplicación de calle, la cosa cambia.
Esto está muy bonito para hacer un piloto de cara a un cliente, en donde
el
rápidamente pueda ver los campos descriptivos de lo que el llama cliente,
y
lo que llama pedido; y la aplicación parezca que hace muchas cosas.

O sea, que según tú, lo que hace Microsoft está mal :)

LEE BIEN. Eso es una demostración de como hacer algo, pero no se tiene por
que aplicar en todos los casos. En Visual Studio 2003 podías arrastrar una
tabla al formulario y te creaba una SqlConnection, y se sabe que no es una
buena practica tener un objeto de este tipo en cada formulario. Pero quedaba
bonito en las presentaciones.

Pero es curioso, me has referenciado una demostración que en la slide del
minuto 2:33, indica que funciona muy bien desde "Web Services, objetos de
negocio... y bases de datos locales" y que esperan que en la versión final
funcione en bases de datos SQL Server remotas o con cualquier cadena de
conexión (esto ultimo no es caracteristico puesto que seguro que terminará
funcionando con SQL directamente). Peo antepone Web Service, y objetos de
negocio a acceso directo a SQL Server, por algo será!.

Pues será por que era más fácil de implementar y acabaron antes, o por
cualquier otra razón irrelevante para nosotros. Lo importante es que
eso va a estar disponible para trabajar con SQL Server, Oracle y
cualquier otro SGBD.

Je, je. A lo mejor es por que tiene mas sentido en las arquitecturas de hoy
en día, y los métodos que tu comentas los mantienen para que seais felices
aquellos que añorais viejos tiempos en los que se hacian aplicaciones
monoliticas en las que cada usuario abre una conexión con la base de datos
de forma directa. Creo que hay una generación anterior a la tuya que
comentaba que lo mejor era utilizar terminales conectados a grandes
sistemas, esos que tenían el fondo negro y la letras en verde. Por que eran
mas robustos y mas potentes. ¿Donde están esos sistemas? La culpa la tiene
Bill Gate con sus ideas innovadoras.

Con respecto a las consultoras y a los tiempos de desarrollo, de eso mejor
ni hablamos, por que cuando te empieze a hablar de herramientas como
CodeSmith, MyGeneration, etc, que reducen el tiempo de desarrollo de una
capa de acceso a datos en un 60%, y facilitan el desarrollo de componentes
de negocio de una forma brutal. Tu diras que se pierde mucho rendimiento,
etc, etc, etc.

Ya, pero lo reducen un 60% después de haberlo aumentado un 1000%, por
ejemplo, por usar una metodología equivocada, ahí está el truco.

Amen, creo que nos has dicho nada de interes en estas lineas, o a lo mejor
no lo pillo.

Saludos.

Saludos

Yo mismo he implementado la clase y digamos que me funciona bien con comandos
simples de diversos tipos, es decir en base a la llave primaria de la
tabla(la cual obtiene del esquema de la base de datos) y obvio con los
valores que el objeto que utiliza dicha clase tiene establecidos, construye
los comandos mas comunes de seleccion, eliminacion, insercion y actualizacion

Crees tu que esto sea correcto? bueno aunque en general entiendo tu idea de
tener los procedimiento almacenados y la razon por la cual los usas pero en
parte como soy el unico programador, esto me implica coste de tiempo en mis
desarrollos pero temo que en un futuro el hacer dependientes mis clases me
pueda dar algun problema... Saludos y muchas gracias



"Miguel Angel Campos" wrote:

Hola Demian,

Según cuentas lo tienes bien planteado, aunque yo utilizaría procedimientos
almacenados en lugar de sentencias SQL, pero todo depende de la siguiente
pregunta que te realizo a continuación.
Has comentado algo de reflection, ¿lo estas haciendo con una libreria
específica de terceros, o has implementado algo tu mismo? No se si estas
utilizando un O/R Mapping u otra cosa.

Un Saludo,

Miguel Angel Campos
MCAD.NET

"Demian" escribió en el mensaje
news:
> De hecho, en mis clases por el momento lo hago como me lo recomiendas, es
> decir, mi capa logica del negocio tiene los comandos Sql que se ejecutaran
> en
> la capa de datos, y utilizo componentes basados en el ambito reflection
> que
> analizan mis objetos para establecer sus propiedades, o bien para leer
> desde
> ellas y construir comandos, entiendo que esto puede no ser muy eficiente
> pero en general me minimiza mucho el tiempo de desarrollo, lo malo es que
> mis
> clases se hacen un poco dependientes de esas clases que construyen los
> comandos
>
> Crees tu que esto esta esta bien planteado? Saludos y gracias de antemano
> por tu respuesta...
>
> "Miguel Angel Campos" wrote:
>
>> Hola Demian,
>>
>> Yo te recomiendo desarrollar una serie de componentes que forman la
>> lógica
>> de negocio, que expondrían toda la funcionalidad que necesites (crear
>> Pedido, obtener Pedido, etc)
>> Dentro de estos componentes utilizaría procedimientos almacenados, es lo
>> recomendado, pero podrías utilizar tambien sentencias SQL, cuidado con la
>> injección de codigo.
>> Y consumiría estos componentes desde la interfaz de usuario, que podría
>> ser
>> Web, Windows, VSTO, etc.
>> ¿Donde situar esos componentes intermedios? por ahora tienes que tomar la
>> decisión en función de las necesidades que tengas para el proyecto (COM+,
>> WebService, Remoting, etc), en un futuro tendras Indigo que permitirá
>> cambiar de uno a otro mediante configuración.
>>
>> Un Saludo,
>>
>> Miguel Angel Campos
>> MCAD.NET
>>
>> "Demian" escribió en el mensaje
>> news:
>> > Hola, tengo una duda en cuanto al modelo de tres capas..
>> >
>> > En general no se donde deben escribirse los comando sql de mi
>> > aplicacion,
>> > no
>> > se si es parte de la capa de datos o bien es parte de la capa logica...
>> >
>> > Entiendo que puedo programar procedimientos almacenados para recuperar
>> > la
>> > información y despues mediante los proveedores de datos de .net
>> > ejecutarlos,
>> > con lo cual obviamente mis sentecnias sql estarian en el lado de la
>> > capa
>> > de
>> > datos y obtendría una aplicacion mas migrable, sin embargo, todas mis
>> > aplicaciones estarían en un servidor y esto podria afectar el
>> > rendimiento
>> > del
>> > mismo.
>> >
>> > Otra opcion es tener una funcion de datos para cada accion que desee
>> > realizar en el servidor, por ejemplo un metodo InsertarPedido, otro
>> > InsertarFactura, y otro mas llamado InsertarAmortizaciones. Esto
>> > estaria
>> > bien, sin embargo alarga el tiempo de desarrollo de aplicaciones.
>> >
>> > La opcion que estopy tomando es tener funciones de datos generales, por
>> > ejemplo
>> > InsertarRegistro o bien InsertarRegistros, a las cuales les paso
>> > comandos
>> > sql o bien una lista de parametros que la funcion pueda reconocer y con
>> > ello
>> > construior un comando que ejecutaria posteriormente. El asunto con esto
>> > que
>> > mi applicacion no es tan migrable y apartentemente mezcla un poco la
>> > logica
>> > de negocio con la capa de datos, sin embargo me gustaría saber si lo
>> > que
>> > estoy haciendo es conveniente y de no serlo cuales son las razones por
>> > las
>> > cuales no debo programar de esta forma.
>> >
>> >
>>
>>
>>

On Fri, 1 Jul 2005 14:35:13 +0200, "Miguel Angel Campos" <SPAMmacampos
ARRUBA .idesarrollaSPAM.com> wrote:

Mi forma de pensar es la generalmente aceptada por los expertos en
bases de datos. De ahí la he sacado.

Tu lo has dicho de los expertos en bases de datos, que no tienen por que ser
los expertos en Arquitectura de sistemas, sólo expertos en bases de datos.

Que tienen una visión mucho más amplia e informada sobre los Sistemas
de Información que la de mayoría de los que se llaman a si mismos
"arquitectos de sistemas", que es solo una manera rimbombante de
llamar a un programador.

Además me estás discutiendo cosas que se explican en la primera semana
de la asignatura de bases de de datos de 2º de carrera.

Un MCDBA puede conocer mucho de SQL Server pero no tener una correcta visión
de posibles arquitecturas, a diferencia de un MCSD o del futuro MCA.

Querrás decir al igual que ellos. Eso no es educación formal sino
entrenamiento en el manejo de productos a cargo de un fabricante de
software, que solo te va a "enseñar" lo que a él le interesa.

Un cursillo de esos nunca puede sustituir a la verdadera educación, y
además se recomienda tener estudios de informática antes de
empezarlos.

(Estas
certificaciones son ejemplos no es necesario tener una para conocer bien un
producto).

Y conocer bien unos productos no es suficiente para tener buenos
conocimientos sobre los fundamentos de la profesión.

Este es el error fundamental de muchos de vosotros los amigos de las
siglas que empiezan por M, que os creeis que por haber hecho un
cursillo de Microsoft ya os lo sabeis todo y no necesitais leer nada
más, especialmente textos de nivel académico.

Si, aunque casi todo lo que enseña esa demo se puede hacer con Delphi
desde hace 10 años.

Perdona pero Delphi no tiene eso desde hace 10 años, por lo menos en la
versión 3 y 4 no lo tenía al nivel que lo tiene Visual Studio 2005.

Lo tiene desde la versión 1.0.

Los TableAdapters son muy parecidos a los TTable y TQuery de Delphi, y
se puede crear una aplicación que mantenga varias tablas con
relaciones maestro detalle, comboboxes etc sin tener que escribir una
sola linea de código. También te crea automáticamente los edits y los
labels cuando arrastras los campos de las tablas a un formulario.

Pero simplemente es eso una demostración de lo que se puede hacer,
arastando
y soltando, pero cuando hacemos una aplicación de calle, la cosa cambia.
Esto está muy bonito para hacer un piloto de cara a un cliente, en donde
el
rápidamente pueda ver los campos descriptivos de lo que el llama cliente,
y
lo que llama pedido; y la aplicación parezca que hace muchas cosas.

O sea, que según tú, lo que hace Microsoft está mal :)

LEE BIEN. Eso es una demostración de como hacer algo, pero no se tiene por
que aplicar en todos los casos.

¿Por que?

¿Por que no funciona? :)

Solo estás tratando de marear la perdiz.

En Visual Studio 2003 podías arrastrar una
tabla al formulario y te creaba una SqlConnection, y se sabe que no es una
buena practica tener un objeto de este tipo en cada formulario. Pero quedaba
bonito en las presentaciones.

Nunca vi a nadie hacer esa tontería en una presentación.

Pues será por que era más fácil de implementar y acabaron antes, o por
cualquier otra razón irrelevante para nosotros. Lo importante es que
eso va a estar disponible para trabajar con SQL Server, Oracle y
cualquier otro SGBD.

Je, je. A lo mejor es por que tiene mas sentido en las arquitecturas de hoy
en día, y los métodos que tu comentas los mantienen para que seais felices
aquellos que añorais viejos tiempos en los que se hacian aplicaciones
monoliticas en las que cada usuario abre una conexión con la base de datos
de forma directa. Creo que hay una generación anterior a la tuya que
comentaba que lo mejor era utilizar terminales conectados a grandes
sistemas, esos que tenían el fondo negro y la letras en verde. Por que eran
mas robustos y mas potentes. ¿Donde están esos sistemas? La culpa la tiene
Bill Gate con sus ideas innovadoras.

¡Terrible!

Creo que te has desenmascarado suficientemente por ti mismo, y no hace
falta seguir discutiendo.

Es muy triste que haya gente que piense que la MSDN es la fuente de
toda la sabiduría.

Ya, pero lo reducen un 60% después de haberlo aumentado un 1000%, por
ejemplo, por usar una metodología equivocada, ahí está el truco.

Amen, creo que nos has dicho nada de interes en estas lineas, o a lo mejor
no lo pillo.

Pues que no tienes que creerte todo lo que digan los panfletos de
propaganda de los fabricantes, ni todo lo que dicen en la teletienda.
Resulta que casi todos los fabricantes exageran las cualidades de sus
productos, ocultan sus defectos y trucan las comparativas. ¿Nunca te
lo habían dicho?


Saludos

Alfredo,

no crees que esta cita tuya :

000
Este es el error fundamental de muchos de vosotros los amigos de las
siglas que empiezan por M, que os creeis que por haber hecho un
cursillo de Microsoft ya os lo sabeis todo y no necesitais leer nada
más, especialmente textos de nivel académico.
000

es algo injusta ?

Particularmente, en el caso de aquellos que sí han leído los tan cacareados
"textos de nivel académico" a que haces referencia, y tienen buena formación
académica, habiendo logrado un grado o posgrados en Ingeniería de Sistemas,
por ejemplo, y *además* tienen las certificaciones/siglas que comienzan con M,
que aparentemente deseas descalificar.

Esa cita, francamente, para alguien que se ufana de la excelencia
que tiene su formación académica, es muy poco académica.




Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
Ven, y hablemos de ASP.NET...

"Alfredo Novoa" wrote in message
news:

On Fri, 1 Jul 2005 14:35:13 +0200, "Miguel Angel Campos" <SPAMmacampos
ARRUBA .idesarrollaSPAM.com> wrote:

Mi forma de pensar es la generalmente aceptada por los expertos en
bases de datos. De ahí la he sacado.

Tu lo has dicho de los expertos en bases de datos, que no tienen por que ser
los expertos en Arquitectura de sistemas, sólo expertos en bases de datos.

Que tienen una visión mucho más amplia e informada sobre los Sistemas
de Información que la de mayoría de los que se llaman a si mismos
"arquitectos de sistemas", que es solo una manera rimbombante de
llamar a un programador.

Además me estás discutiendo cosas que se explican en la primera semana
de la asignatura de bases de de datos de 2º de carrera.

Un MCDBA puede conocer mucho de SQL Server pero no tener una correcta visión
de posibles arquitecturas, a diferencia de un MCSD o del futuro MCA.

Querrás decir al igual que ellos. Eso no es educación formal sino
entrenamiento en el manejo de productos a cargo de un fabricante de
software, que solo te va a "enseñar" lo que a él le interesa.

Un cursillo de esos nunca puede sustituir a la verdadera educación, y
además se recomienda tener estudios de informática antes de
empezarlos.

(Estas
certificaciones son ejemplos no es necesario tener una para conocer bien un
producto).

Y conocer bien unos productos no es suficiente para tener buenos
conocimientos sobre los fundamentos de la profesión.

Este es el error fundamental de muchos de vosotros los amigos de las
siglas que empiezan por M, que os creeis que por haber hecho un
cursillo de Microsoft ya os lo sabeis todo y no necesitais leer nada
más, especialmente textos de nivel académico.

Si, aunque casi todo lo que enseña esa demo se puede hacer con Delphi
desde hace 10 años.

Perdona pero Delphi no tiene eso desde hace 10 años, por lo menos en la
versión 3 y 4 no lo tenía al nivel que lo tiene Visual Studio 2005.

Lo tiene desde la versión 1.0.

Los TableAdapters son muy parecidos a los TTable y TQuery de Delphi, y
se puede crear una aplicación que mantenga varias tablas con
relaciones maestro detalle, comboboxes etc sin tener que escribir una
sola linea de código. También te crea automáticamente los edits y los
labels cuando arrastras los campos de las tablas a un formulario.

Pero simplemente es eso una demostración de lo que se puede hacer,
arastando
y soltando, pero cuando hacemos una aplicación de calle, la cosa cambia.
Esto está muy bonito para hacer un piloto de cara a un cliente, en donde
el
rápidamente pueda ver los campos descriptivos de lo que el llama cliente,
y
lo que llama pedido; y la aplicación parezca que hace muchas cosas.

O sea, que según tú, lo que hace Microsoft está mal :)

LEE BIEN. Eso es una demostración de como hacer algo, pero no se tiene por
que aplicar en todos los casos.

¿Por que?

¿Por que no funciona? :)

Solo estás tratando de marear la perdiz.

En Visual Studio 2003 podías arrastrar una
tabla al formulario y te creaba una SqlConnection, y se sabe que no es una
buena practica tener un objeto de este tipo en cada formulario. Pero quedaba
bonito en las presentaciones.

Nunca vi a nadie hacer esa tontería en una presentación.

Pues será por que era más fácil de implementar y acabaron antes, o por
cualquier otra razón irrelevante para nosotros. Lo importante es que
eso va a estar disponible para trabajar con SQL Server, Oracle y
cualquier otro SGBD.

Je, je. A lo mejor es por que tiene mas sentido en las arquitecturas de hoy
en día, y los métodos que tu comentas los mantienen para que seais felices
aquellos que añorais viejos tiempos en los que se hacian aplicaciones
monoliticas en las que cada usuario abre una conexión con la base de datos
de forma directa. Creo que hay una generación anterior a la tuya que
comentaba que lo mejor era utilizar terminales conectados a grandes
sistemas, esos que tenían el fondo negro y la letras en verde. Por que eran
mas robustos y mas potentes. ¿Donde están esos sistemas? La culpa la tiene
Bill Gate con sus ideas innovadoras.

¡Terrible!

Creo que te has desenmascarado suficientemente por ti mismo, y no hace
falta seguir discutiendo.

Es muy triste que haya gente que piense que la MSDN es la fuente de
toda la sabiduría.

Ya, pero lo reducen un 60% después de haberlo aumentado un 1000%, por
ejemplo, por usar una metodología equivocada, ahí está el truco.

Amen, creo que nos has dicho nada de interes en estas lineas, o a lo mejor
no lo pillo.

Pues que no tienes que creerte todo lo que digan los panfletos de
propaganda de los fabricantes, ni todo lo que dicen en la teletienda.
Resulta que casi todos los fabricantes exageran las cualidades de sus
productos, ocultan sus defectos y trucan las comparativas. ¿Nunca te
lo habían dicho?


Saludos