Framework/Biblioteca + ORM

Hola...

queremos hacer un sistema basado en capas, para efectos de escalabilidad e
independizarnos lo más posible del RDBMs y los canales de entrada/salida.
Esto dado que algunos módulos del sistema ya los tiene un cliente por lo que
hay que integrarlo, pero otro no y por ende habrá que construirlo.
El sistema tendría una complejidad media (100 usuarios, con DB en el rango
de los 10GB)
La problemática es de arquitectura más que de programación específica.
Gracias.


Néstor.


"Alfredo Novoa" escribió en el mensaje
news:

On Thu, 20 Jul 2006 19:16:16 -0400, "news.microsoft.com"
wrote:

¿Alguien podría aconsejarme en lo siguiente...?
Tengo que comenzar a desarrollar un sistema (Smart Client + WebServices +
RDBMS)

No se muy bien para que puedes querer WebServices si ya tienes un
SQL-DBMS. ¿Para comprimir tu los datos y ahorrar ancho de banda?

Si quisiese tener un servidor intermedio yo usaría TCP/IP puro y duro,
aunque supongo que a cualquier cosa que vaya por el puerto 80 se le
puede llamar WebService.

y me ha resultado dificil determinar la arquitectura respecto a:
- Que Framework o Biblioteca de apoyo me conviene utilizar: Enterprise
Library, Spring.NET u otro?

Mira lo que trae cada biblioteca a ver si encuentras algo en ella que
te pueda servir. He mirado un poco Spring .Net y no he visto nada
interesante.

- Que ORM me convendría más utilizar junto a lo anterior? ... (larga lista
de posibilidades)

Ninguno. El ORM es una tontería. Para presentar datos puedes usar
DataSets.


Saludos
Alfredo

On Fri, 21 Jul 2006 12:21:47 -0400, "news.microsoft.com"
wrote:

queremos hacer un sistema basado en capas, para efectos de escalabilidad e
independizarnos lo más posible del RDBMs y los canales de entrada/salida.

Un buen SQL DBMS ya es escalable. Esto hay que tenerlo en cuenta.

Independizarte mucho del DBMS suele ser una mala idea por que si no lo
haces con mucho cuidado puede llevarte a perder muchas de las ventajas
de usar un DBMS.

Esto es lo que suele pasar con los sistemas que usan un ORM que suelen
llegar al extremo de infrautilizar al DBMS como un mero gestor de
archivos.

Para hacerte independiente del DBMS lo mejor suele ser aprovechar a
tope todos los servicios del DBMS y crear versiones para los DBMS que
quieras soportar, que al final no son más de dos o tres.

Tener que adaptar un poco de código SQL para distintos SGBD suele
suponer muchísimo menos trabajo que implementar la lógica de negocio
con código procedimental.

Esto dado que algunos módulos del sistema ya los tiene un cliente por lo que
hay que integrarlo, pero otro no y por ende habrá que construirlo.
El sistema tendría una complejidad media (100 usuarios, con DB en el rango
de los 10GB)

Entonces no es un sistema grande. Dos capas pueden ser suficientes,
aunque lo ideal sería un DBMS distribuido.

En caso de tener que crear un servidor intermedio yo lo haría lo más
sencillo que fuese posible. Crearía una especia de balanceador de
carga que además mantuviese sincronizados los distintos servidores de
datos.

Lo más importante es que el middleware ofrezca a los clientes una
interfaz relacional.

Lo ideal sería que el middleware fuese transparente y las aplicaciones
no pudiesen distinguir si se está trabajando con dos o más capas, y
que pudieses cambiar de dos a tres capas y viceversa en cualquier
momento sin tener que tocar las aplicaciones.

Una forma de conseguir esto podría ser accediendo al servidor
intermedio con un DataProvider. Así podrías pasar de dos a tres capas
simplemente cambiando la cadena de conexión.


Saludos
Alfredo

Que bien... voy a estudiar ese enfoque y averiguar acerca de los
DataProvider.
Muchas Gracias y saludos


Néstor.

"Alfredo Novoa" escribió en el mensaje
news:

On Fri, 21 Jul 2006 12:21:47 -0400, "news.microsoft.com"
wrote:

queremos hacer un sistema basado en capas, para efectos de escalabilidad e
independizarnos lo más posible del RDBMs y los canales de entrada/salida.

Un buen SQL DBMS ya es escalable. Esto hay que tenerlo en cuenta.

Independizarte mucho del DBMS suele ser una mala idea por que si no lo
haces con mucho cuidado puede llevarte a perder muchas de las ventajas
de usar un DBMS.

Esto es lo que suele pasar con los sistemas que usan un ORM que suelen
llegar al extremo de infrautilizar al DBMS como un mero gestor de
archivos.

Para hacerte independiente del DBMS lo mejor suele ser aprovechar a
tope todos los servicios del DBMS y crear versiones para los DBMS que
quieras soportar, que al final no son más de dos o tres.

Tener que adaptar un poco de código SQL para distintos SGBD suele
suponer muchísimo menos trabajo que implementar la lógica de negocio
con código procedimental.

Esto dado que algunos módulos del sistema ya los tiene un cliente por lo
que
hay que integrarlo, pero otro no y por ende habrá que construirlo.
El sistema tendría una complejidad media (100 usuarios, con DB en el rango
de los 10GB)

Entonces no es un sistema grande. Dos capas pueden ser suficientes,
aunque lo ideal sería un DBMS distribuido.

En caso de tener que crear un servidor intermedio yo lo haría lo más
sencillo que fuese posible. Crearía una especia de balanceador de
carga que además mantuviese sincronizados los distintos servidores de
datos.

Lo más importante es que el middleware ofrezca a los clientes una
interfaz relacional.

Lo ideal sería que el middleware fuese transparente y las aplicaciones
no pudiesen distinguir si se está trabajando con dos o más capas, y
que pudieses cambiar de dos a tres capas y viceversa en cualquier
momento sin tener que tocar las aplicaciones.

Una forma de conseguir esto podría ser accediendo al servidor
intermedio con un DataProvider. Así podrías pasar de dos a tres capas
simplemente cambiando la cadena de conexión.


Saludos
Alfredo

On Fri, 21 Jul 2006 19:42:39 -0400, "Néstor Sánchez A."
wrote:

Que bien... voy a estudiar ese enfoque y averiguar acerca de los
DataProvider.

Aquí tienes bastante información:

http://msdn.microsoft.com/library/d...ovider.asp


Saludos
Alfredo