Pregunta

Como alguien que no ha utilizado ninguna de las tecnologías en proyectos del mundo real, me pregunto si alguien sabe cómo estas dos se complementan entre sí y en qué medida se superponen sus funcionalidades.

¿Fue útil?

Solución

LINQ to SQL te obliga a utilizar el patrón de tabla por clase.Los beneficios de usar este patrón son que es rápido y fácil de implementar y requiere muy poco esfuerzo para que su dominio funcione según una estructura de base de datos existente.Para aplicaciones simples, esto es perfectamente aceptable (y muchas veces incluso preferible), pero para aplicaciones más complejas los desarrolladores a menudo sugerirán usar un diseño impulsado por dominio patrón en su lugar (que es lo que facilita NHibernate).

El problema con el patrón tabla por clase es que la estructura de su base de datos tiene una influencia directa sobre el diseño de su dominio.Por ejemplo, digamos que tiene una tabla Clientes con las siguientes columnas para contener la información de la dirección principal de un cliente:

  • Dirección
  • Ciudad
  • Estado
  • Cremallera

Ahora, digamos que también desea agregar columnas para la dirección postal del cliente, por lo que agrega las siguientes columnas a la tabla Clientes:

  • Dirección postal
  • CorreoCiudad
  • Estado de correo
  • Correo postal

Al usar LINQ to SQL, el objeto Cliente en su dominio ahora tendría propiedades para cada una de estas ocho columnas.Pero si estuviera siguiendo un patrón de diseño impulsado por un dominio, probablemente habría creado una clase de Dirección y su clase Cliente tendría dos propiedades de Dirección, una para la dirección postal y otra para su dirección actual.

Este es un ejemplo simple, pero demuestra cómo el patrón de tabla por clase puede conducir a un dominio algo maloliente.Al final, depende de ti.Nuevamente, para aplicaciones simples que solo necesitan la funcionalidad CRUD (crear, leer, actualizar, eliminar) básica, LINQ to SQL es ideal debido a su simplicidad.Pero personalmente me gusta usar NHibernate porque facilita un dominio más limpio.

Editar:@lomaxx: Sí, el ejemplo que utilicé fue simplista y podría haberse optimizado para funcionar bien con LINQ to SQL.Quería mantenerlo lo más básico posible para aclarar el punto.Sin embargo, el punto sigue siendo que hay varios escenarios en los que hacer que la estructura de su base de datos determine la estructura de su dominio sería una mala idea, o al menos conduciría a un diseño OO subóptimo.

Otros consejos

Dos puntos que se han pasado por alto hasta ahora:

También lo nuevo interfaz fluida con Nhibernate Parece hacer que sea menos doloroso configurar el mapeo de Nhibernate.(Eliminando uno de los puntos débiles de Nhibernate)

Actualizar

Linq to Nhiberate es mejor en Nhiberate v3 que ahora está en alfa.Parece que Nhiberate v3 podría enviarse a finales de este año.

El Marco de la entidad a partir de .net 4 también empieza a parecer una opción real.

@Kevin:Creo que el problema con el ejemplo que estás presentando es que estás utilizando un diseño de base de datos deficiente.Pensé que crearías una tabla de clientes y una tabla de direcciones y normalizarías las tablas.Si haces eso, definitivamente puedes usar Linq To SQL para el escenario que estás sugiriendo.Scott Guthrie tiene un gran serie de publicaciones sobre el uso de Linq To SQL que le recomiendo encarecidamente que consulte.

No creo que se pueda decir que Linq y NHibernate se complementan entre sí, ya que eso implicaría que podrían usarse juntos, y si bien esto es posible, es mucho mejor que elijas uno y te ciñas a él.

NHibernate le permite asignar las tablas de su base de datos a los objetos de su dominio de una manera muy flexible.También le permite utilizar HBL para consultar la base de datos.

Linq to SQL también le permite asignar los objetos de su dominio a la base de datos; sin embargo, utiliza la sintaxis de consulta de Linq para consultar la base de datos.

La principal diferencia aquí es que la sintaxis de consulta de Linq es El compilador lo verifica en el momento de la compilación para garantizar que sus consultas sean válidas.

Algunas cosas a tener en cuenta con linq es que solo está disponible en .net 3.x y solo es compatible con VS2008.NHibernate está disponible en 2.0 y 3.x, así como en VS2005.

Algunas cosas a tener en cuenta con NHibernate es que no genera los objetos de su dominio ni los archivos de mapeo.Debes hacer esto manualmente.Linq puede
haz esto automáticamente por ti.

Fluent NHibernate puede generar sus archivos de mapeo basándose en convenciones simples.Sin escritura XML y fuertemente tipado.

Recientemente trabajé en un proyecto en el que necesitábamos cambiar de Linq To SQL a NHibernate por razones de rendimiento.Especialmente la forma en que L2S materializa los objetos parece más lenta que el ídem de NHibernate y la gestión de cambios también es bastante lenta.Y puede resultar difícil desactivar la gestión de cambios en escenarios específicos en los que no es necesaria.

Si va a utilizar sus entidades desconectadas del DataContext (en escenarios WCF, por ejemplo), es posible que tenga muchos problemas para conectarlas nuevamente al DataContext para actualizar los cambios.No he tenido problemas con eso con NHibernate.

Lo que extrañaré de L2S es principalmente la generación de código que mantiene las relaciones actualizadas en ambos extremos de las entidades.Pero supongo que también existen algunas herramientas para que NHibernate haga eso...

¿Puedes aclarar qué quieres decir con "LINQ"?

LINQ no es una tecnología de acceso a datos, es simplemente una característica del lenguaje que admite consultas como una construcción nativa.Puede consultar cualquier modelo de objetos que admita interfaces específicas (p. ej.IQueryable).

Mucha gente se refiere a LINQ To SQL como LINQ, pero eso no es del todo correcto.Microsoft acaba de lanzar LINQ To Entities con .NET 3.5 SP1.Además, NHibernate tiene una interfaz LINQ, por lo que puede usar LINQ y NHibernate para acceder a sus datos.

Por LINQ, supongo que te refieres a LINQ to SQL porque LINQ, por sí solo, no tiene ninguna base de datos asociada a él.Es solo un lenguaje de consulta que tiene una gran cantidad de azúcar sintáctico para que parezca SQL.

En los ejemplos más básicos, NHibernate y LINQ to SQL parecen estar resolviendo el mismo problema.Una vez que lo haya aprobado, pronto se dará cuenta de que NHibernate admite muchas funciones que le permiten crear modelos de dominio verdaderamente ricos.También hay un proyecto LINQ to NHibernate que le permite usar LINQ para consultar NHibernate de la misma manera que usaría LINQ to SQL.

Primero separemos dos cosas diferentes:El modelado de bases de datos se preocupa por los datos, mientras que el modelado de objetos se preocupa por las entidades y relaciones.

La ventaja de Linq-to-SQL es generar rápidamente clases a partir del esquema de la base de datos para que puedan usarse como objetos de registro activo (consulte la definición del patrón de diseño de registro activo).

La ventaja de NHibernate es permitir flexibilidad entre el modelado de objetos y el modelado de bases de datos.La base de datos se puede modelar para reflejar mejor sus datos teniendo en cuenta el rendimiento, por ejemplo.Mientras que el modelado de objetos reflejará mejor los elementos de la regla de negocio utilizando un enfoque como el diseño basado en dominio.(ver el comentario de Kevin Pang)

Con bases de datos heredadas con modelado deficiente y/o convenciones de nomenclatura, Linq-to-SQL reflejará estas estructuras y nombres no deseados en sus clases.Sin embargo, NHibernate puede ocultar este lío con los mapeadores de datos.

En proyectos nuevos donde las bases de datos tienen buenos nombres y baja complejidad, Linq-to-SQL puede ser una buena opción.

Sin embargo puedes usar NHibernate fluido con asignaciones automáticas para este mismo propósito con el mapeo como convención.En este caso, no se preocupa por ningún mapeador de datos con XML o C# y deja que NHibernate genere el esquema de la base de datos a partir de sus entidades basándose en una convención que puede personalizar.

Por otro lado, la curva de aprendizaje de Linq-to-SQL es menor que la de NHibernate.

O podrías utilizar el proyecto Castle ActiveRecords.Lo he estado usando por un corto tiempo para desarrollar algún código nuevo para un proyecto heredado.Utiliza NHibernate y funciona en el patrón de registro activo (sorprendente dado su nombre, lo sé).No lo he intentado, pero supongo que una vez que lo haya usado, si siente la necesidad de acudir directamente al soporte de NHibernate, no sería demasiado hacerlo para parte o la totalidad de su proyecto.

Como escribió "para una persona que no ha usado ninguno de ellos", Linq a SQL es fácil de usar para que cualquiera pueda usarlo fácilmente, también admite procedimientos, lo que ayuda la mayor parte del tiempo.Supongamos que desea obtener datos de más de una tabla, luego escribir un procedimiento y arrastrar ese procedimiento al diseñador y creará todo para usted, suponga que su nombre de procedimiento es "Custom_order_lineitem" que obtiene un registro de las tres tabla y luego escribe solo escriba.

MyDataContext db = new MyDataContext();
List<CUSTOMER_ORDER_LINEITEMResult> records = db.CUSTOMER_ORDER_LINEITEM(pram1, param2 ...).ToList<CUSTOMER_ORDER_LINEITEMResult>();

También puedes usar tu objeto de registros en el bucle foreach, que no es compatible con NHibernate.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top