Ayuda modelo de tres capas...

A lo mejor no he entendido bien el punto.. con SGDB te refieres a algun
manejador de bases de datos quiero suponer...

Sin embaro con lo que me comentas aparentemente no existen componentes
reutilizables, o bien donde quedaria ese codigo que en muchas ocasiones es
tan repetitivo como por ejemplo el calculo de algun Impuesto, quedaría en una
clase separada de la capa de presentacion?



"Alfredo Novoa" wrote:

On Thu, 30 Jun 2005 11:00:03 -0700, Demian
wrote:

>Antes que nada agdezco el tiempo de contestar mi pregunta, sin embargo me
>surge una pequeña en relación a como puede trabajar tu componente...
>
>Voy a atratar de plantear de manera muy generalizada la forma en que
>interpreto que pueden tabajar tus clases para el ejemplo que me das del
>datagrid..
>
>1. Tendrias un componenete(obvio simplificado) mas o menos asi..
>Public Class ComponenteSql
> Dim Tabla as string
> Dim InsertComand as string
> Public Function GenerarComandoInsert() as string
> ' mas algunas otras propiedades que pueda tener el componente
>end class
>2. Al insertar un nuevo registro pasaría lo siguiente:
>'supongamos que esta instanciada la clase del componente, que estamos
>'insertando un nuevo pedido y que existe una capa logica que hace las
>validaciones
>'de la nueva fila insertada

No, esas validaciones le corresponden al SGBD.

>Private sub On_RowChanging
> ' La funcion GenerarComandoInsert probablemente se basaria en el
> ' esquema de la tabla para interpretar lo que se desea hacer

Exacto.

> Componente.GenerarComandoInsert
>
> 'En esta funcion se validaria que el datarow que se esta insertando
>tenga los
> 'valores adecuados (pertenece a la capa logica del negocio)

No, simplemente lo generas y listo. Si hay algo mal ya te lo dirá el
SGBD.

>Abusando de tu confianza te pregunto si de esta manera es como funcionaria
>mas o menos?

Si, lo has entendido muy bien.

>, o cuales modificaciones le harias al codigo que planteo...

Pues lo más importante es dejar al SGBD que compruebe la lógica de
negocio. Eso te ahorra un montón de código y de trabajo.

Un SGBD es un "motor" de lógica de negocio. El Modelo Relacional es
una aplicación directa de la teoría de conjuntos y la lógica de
predicados de primer orden. El éxito del Modelo Relacional se debe a
que es una idea muy buena utilizar la lógica matemática para la lógica
de negocio.


Una buena noticia es que el componente del que hablo ya está
disponible en Visual Studio 2005 y se llama TableAdapter

http://msdn2.microsoft.com/library/bz9tthwx(en-us,vs.80).aspx.

Aquí tienes un enlace con una demostración:

http://www.intsight.com/whidbeydb/whidbey.html

Creo que las ventajas quedan bastante claras :)



Saludos

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

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

Hola Alfredo,

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.

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.

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.

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

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.

Un Saludo,

Miguel Angel Campos
MCAD.NET

"Alfredo Novoa" escribió en el mensaje
news:

On Thu, 30 Jun 2005 21:28:10 +0200, "Miguel Angel Campos"
<SPAMmacampos ARRUBA .idesarrollaSPAM.com> wrote:

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

Esto está muy bien si tus objetivos son maximizar el tiempo de
desarrollo y los costes de mantentimiento (y no te importa tener una
aplicación muy lenta), algo que desean muchas consultoras.

Si tus objetivos son los contrarios es mucho mejor hacer algo como
esto:

http://www.intsight.com/whidbeydb/whidbey.html


Saludos

On Thu, 30 Jun 2005 15:20:04 -0700, Demian
wrote:

A lo mejor no he entendido bien el punto.. con SGDB te refieres a algun
manejador de bases de datos quiero suponer...

SGBD = Sistema de Gestión de Bases de Datos

Sin embaro con lo que me comentas aparentemente no existen componentes
reutilizables

Si, los DataSets y los TableAdapters los puedes usar en muchas
aplicaciones.

, o bien donde quedaria ese codigo que en muchas ocasiones es
tan repetitivo como por ejemplo el calculo de algun Impuesto, quedaría en una
clase separada de la capa de presentacion?

Habría que implementarlo en el SGBD con una vista por ejemplo, así
estaría disponible para que lo usasen todas las aplicaciones que fuese
necesario.

Así quedaría en una capa separada de la capa de presentación, es decir
separado de las aplicaciones.


Saludos