Para que sirve LINQ?

Hola.
Estaba mapeando objetos a sql server 2005. El problema era el siguiente:
Tengo un objeto Empresa que tiene un conjunto de objetos Licitacion, Cada
Licitacion tiene un conjunto de objetos Articulo, los cuales, as su vez
tienen un objeto Proveedor. Como la empresa debe conocer a sus proveedores,
tambien tiene una coleccion de Proveedor. Tambien tenemos la coleccion de
objetos Entrega, etc, etc.
Imaginense lo que es mapear todo esto a una base de datos, por ejemplo para
agregar una Licitacion ¡¡todo lo que hay que verificar para asegurarnos que
no falle!! ¿Y si eliminamos una Licitacion...!!?

Asi que me puse a ver un poco por arriba LINQ. Enseguida me di cuenta que
LINQ con su diseñador, hace todo esto (y mucho mas). Todo lo que tenemos que
hacer es arrastrar las tablas con el mouse. Tal vez sea un problema el hecho
de que a veces nuestro diseño de objetos no coincide exactamente con el de la
DB, pero seguramente no debe ser muy dificil solucionarlo.

Lo que tambien pude ver, es que todo luce como para usarlo como un origen de
datos. Y aunque no me interiorice mucho en esto, me pregunto ¿para que? ¿para
que agregar una capa más? si al final terminaremos con un dataset tipado o
algo asi. ¿por que no conectar el origen de datos directamente a la base de
datos?.

yo pensaba que cuando creas un origen de datos, ese del cual se pueden
arrastrar los campos al form ya te crea los texbox, combos, etc para mostrar
los datos, lo que se crea es un dataset tipado. Pero si no es asi, lo que
dije de una capa de mas, no corresponde.

A mi, lo que en realidad me interesa es mapear objetos a db, ya que las db
orientada a objetos no parecen ser una buena opción.

En cuanto a eliminar el modelo de datos:

es justamente lo que no quiero
hace, desperdiciar las ventajas que no da el paradigma de POO.

Como dije al principio, mi objetivo es trabajar con el modelo de Objetos. He
leido por todas partes que apegarse a un adecuado diseño de objetos hace que
la aplicacion sea mas facil de mantener y escalar, y tambien puede reducir la
complejidad.

Yo hice, con vb6, algunas aplicaciones que terminaron siendo muy complejas y
cuesta mucho cada vez que hay hacer alguna modificacion. Ahora que estoy
aprendiendo POO, me doy cuenta que habria sido mucho mas facil si lo hubiera
hecho con objetos.

Mas facil para programar, depurar, hacer modificaciones y
agregar funcionalidad. Algunas de la modificaciones que me llevaron mucho
trabajo porque cada cambio impactaba en muchos lugares, con objetos lo
hubiera hecho con solo agregar una clase.

Pero el problema de trabajar con un modelo de objeto es mapear a la base de
datos, entonces toda las ventajas que tiene la POO, al final son superadas
por las complicaciones de la persistencia.