Entidades Linq 2 SQL o Linq

Question

Estoy empezando a diseñar una nueva aplicación y lo que me pregunto es la opinión de las personas sobre Linq2SQL o Linq2Entities y lo que ellos sienten es la mejor tecnología para un desarrollo rápido.

También estoy investigando los servicios de datos de ADO.net.

Answer 1

Soy un gran fan de LINQ to SQL si cumple con los siguientes requisitos de diseño:

• MS SQL Server como el motor DB
• desarrollo RAD
• 1 - 1 mapeo de clases es todo eso es requerido

No he trabajado mucho con Entity Framework, pero por lo que sé y lo que he hecho es que no tiene un rendimiento tan bueno cuando se genera desde la misma base de datos que LINQ a los usos de SQL.

El menor rendimiento se debe a la naturaleza de Entity Framework, utiliza ADO en lugar de proveedores específicos para el servidor de base de datos que está utilizando.

Answer 2

Yo diría que para un esquema de base de datos simple a moderado, Linq2SQL funciona muy bien y es más fácil de configurar y usar. Esto es lo que uso para mi ORM con algunos pequeños ajustes a través de clases parciales para soportar validación y autorización/auditoría. Uso el diseñador de DBML y agrego mis tablas/relaciones. Cambio el DataContext para hacerlo abstracto y construir una implementación concreta que me permita proporcionar implementaciones de mis funciones con valores de tabla/procedimientos almacenados (que se mapean en el contexto de datos como métodos) que proporcionan ganchos para auditar y autorizar. Implemento métodos parciales en las clases de entidad para OnValidate y OnLoad para hacer tanto la validación como la autorización en el nivel de la tabla. Encuentro que esto es prácticamente todo lo que necesito. Últimamente, he estado definiendo una interfaz y un contenedor para el contexto concreto de datos, así como para permitirme simularlo en mis pruebas unitarias.

Answer 3

Mi voto va a Linq-to-SQL. Se adapta a su escenario de desarrollo rápido; fácil de comenzar, fácil de usar. Además, genera consultas SQL buenas/eficientes a partir de expresiones Linq.

LINQ-a-Entidades es torpe, si intenta utilizar cualquiera de las características 'avanzadas' que se supone que mantenerlo en reserva de L2S entonces usted tendrá que empezar a editar el archivo de modelo EDMX utilizando un editor XML que (Pronto se encontrará con 'limitaciones' en el diseñador, donde la única solución/solución recomendada por Microsoft es usar un editor XML para manipular manualmente el EDMX). Además de eso, tiende a generar consultas SQL realmente pobres/ineficientes.

Microsoft dice que la próxima versión de Entity Framework será mucho mejor y admitirá todas las ventajas de L2S. Sin embargo, la próxima versión no se lanzará próximamente, por lo que hasta entonces L2S es su mejor opción.

Answer 4

Linq to SQL es un callejón sin salida en estos días porque Microsoft no va a actualizarlo nunca más. Lo usé por un tiempo para mis propios proyectos, pero encontré que tenía poco poder en comparación con SQL real. Por supuesto, puede parecer más fácil ejecutarlo en el corto plazo, pero a lo largo del ciclo de desarrollo de su aplicación descubrirá que disfruta más del poder de SQL.

Creo que LINQ TO SQL solo debe ser adoptado por aquellos que son severamente dependientes de las capas de abstracción de la infraestructura y no tienen el tiempo/energía/deseo de buscar SQL.

Una cosa más que debes recordar es que la capa adicional entre SQL y tu aplicación tiene su propio costo.La diferencia de velocidad no es algo que notará fácilmente, pero está ahí.

Personalmente recomiendo que alguien que está empezando a cabo debe graduarse directamente a SQL y LINQ to SQL dar un fallo.

Answer 5

Recomendaría buscar soluciones que no sean de Microsoft para ORM. nHibernate es una gran solución que tiene todas las ventajas de ambos frameworks y más. Sí, es una curva de aprendizaje más pronunciada, pero con fluidez nHibernate ayuda con eso. Vale la pena el esfuerzo.

Answer 6

Nadie puede decir Usted defenitly lo es mejor.

Ambos técnicos tienen problemas (NHibernate también tiene problemas).

Estoy usando Linq-to-SQL y estoy feliz con él. Para mi opinión, los problemas en Linq-to-SQL son menores que en EF^_ ^.

Answer 7

Para el uso con los servicios de datos de ADO.NET (que usted menciona), Entity Framework es el que funciona fuera de la caja. Si desea actualizar los datos con LINQ-to-SQL (a través de los servicios de datos ADO.NET), debe realizar algún trabajo para implementar IUpdatable. Afortunadamente, he estado escribiendo sobre eso this week.

Mis pensamientos generales entre los dos están cubiertos here, pero he suavizado un poco desde entonces, vea here.

Básicamente, en este momento prefiero LINQ a SQL, pero espero EF que sea más fácil de usar en la próxima versión. Por lo tanto, estoy trabajando para que LINQ-to-SQL funcione con ADO.NET Data Services.

Answer 8

Creo que Linq 2 Sql es una excelente opción. Unos pocos puntos:

• Está muy rápido, recuerdo haber leído una entrada de blog sobre al Rico Mariani's Performance Tidbits durante L2S beta, donde se mide que sea casi tan rápido como edad ADO.Net llano, y que fue durante su beta .
• Puede hacer las dos consultas LINQ, así como el trabajo con los procedimientos almacenados y buena sql vieja si te gusta eso, y aún así obtener los datos de mapeo objeto hecho por ti.
• El hecho de que Stackoverflow use L2S demuestra que puede funcionar en un sitio web a gran escala.
• Es mucho más liviano que Entity Framework, que es bueno y malo dependiendo de lo que necesite. En general, si sus necesidades no son súper avanzadas, por lo general puede solucionar cualquier problema con bastante rapidez.

Answer 9

Sí, estuvo de acuerdo con Slace.

Sólo tenga cuidado en el marco que usted elija, para garantizar que cumple todas sus necesidades.

Por ejemplo, recientemente he destripado a cabo Marco de la entidad a partir de un proyecto de trabajo después de trabajar con él bastante sólidamente en el último par de semanas, ya que no facilitaba mis necesidades, debido principalmente a: -

1. El things you can't do in Linq to Entities (como mapear a tipos de en .net enum (grr) y la molestia de recibir 'NotSupportedException' casi en cada turno si intenta hacerse rico en su enunciado de consulta linq invocando funciones o llamadas a métodos (ver enlace)).
2. Falta de carga lenta nativa (entiendo que hay herramientas como EF Lazy LoadGen para facilitar esto, pero no era algo que quisiera incluir).

Aparte de eso, manda y el marco parecía sencillo y ordenado, y la razón por la que fui con EF fue:

1. yo creía EF fue el blanco más para el desarrollo empresarial y pensé L2S era más para aficionados y fue un marco limitado. Sin embargo, con mayor comprensión y personalmente, sin necesitar nada en EF que no pude hacer con L2S, estoy contento con L2S. Especialmente si se adapta al stackoverflow, la escalabilidad y la eficiencia están cubiertas para mí.
2. Opción para DBMS múltiples (todavía estoy viendo esto en acción)
3. Se rumoreaba que Microsoft era dropping support and investment on Linq to SQL.
4. Me encanta el hecho de que puede actualizar tablas y cambios de bases de datos dentro de EF .edmx sin tener que eliminar el modelo de esquema existente (que está obligado a hacer en Linq a SQL). Sin embargo, no es muy molesto a menos que haya personalizado cualquier propiedad en su esquema L2S (.dbml).

Lectura adicional (otro SO post):
Is LINQ to SQL Dead or Alive?

me gustaría elegir EF, realmente no sé qué hacer con el L2S vs EF debarcle, y si realmente es L2S un pato muerto, encogerse de hombros. mi principal queja es que con EF es la excepción NotSupportedException - Podría evitar la carga lenta si pudiera realizar llamadas a métodos en linq sin obtener esto ...

Answer 10

Pensamos que L2S fue genial hasta que intentamos hacer actualizaciones. Entonces fue patético. Mi colega estaba haciendo la mayor parte de este trabajo mientras yo hacía otras cosas. Habló sobre EF y las formas en que la excesiva capacidad de configuración lo hacía complicado de usar.

Sugerí que, dado que apostamos a MSSQL y eso no va a cambiar, podría piratear todo el material de abstracción de proveedores de bases de datos. Algún tiempo después, me dijo que era una buena sugerencia y que su código era mucho más simple y menos complicado de mantener.

---

Soy curioso en cuanto a la base sobre la que esta respuesta ha sido votado abajo. Describe la experiencia real y analiza una estrategia alternativa y el éxito relativo de ese enfoque. La votación a la baja es para respuestas que son engañosas, objetivamente incorrectas o simplemente trolling.

Sucede que he cambiado mi posición en todo el asunto EF vs. L2S, pero eso no cambia el hecho de que votar negativamente algo simplemente porque expresa una opinión diferente a la suya es infantil y totalmente contrario al espíritu de StackOverflow.

Answer 11

Esta es una pregunta muy antigua, pero la animadora de LinqToSql de las respuestas más votadas me preocupa. Hay desventajas significativas para LinqToSql.

Do not use the Visual Studio 2008 LinqToSql O/R Designer

The drawbacks of adopting Linq To Sql

Dicho esto, hay algunas desventajas significativas para ADO.NET Entity Framework también.

Hay muchas opciones, mucho mejores disponibles (NHibernate siendo la mejor opción todo el tiempo en este momento).