Cuando se lanzó linq a entidades, todos dicen que linq to sql está muerto.ASP.NET MVC + LINQ to SQL or Entities?
Pero la mayoría de los libros y proyectos de ejemplo de los empleados de microsoft usan mvc + linq a sql.
¿Hay alguna razón para eso? El linq a sql parece mejor para POCO, ¿verdad?
Linq to SQL had its origins in a thought experiment. Linq necesitaba una prueba de concepto, y Linq a SQL siempre que.
Desde entonces, muchos en la comunidad de usuarios (incluyendo a few prominent Microsoft employees) han adoptado Linq a SQL como el SQL ligero ORM de elección, especialmente para proyectos pequeños como NerdDinner.
El furor comenzó con this post por el equipo de ADO.NET. En él, dijeron que se mantendrá Linq a SQL y se agregarán características basadas en la retroalimentación de la comunidad de usuarios, pero que el Marco de la Entidad sería el foco principal de los futuros esfuerzos de acceso a los datos.
Muchos en la comunidad de usuarios interpretaron este movimiento como "Microsoft is killing Linq to SQL".
Microsoft no ayudó cuando disabled the provider model for Linq to SQL by sealing some critical classes, haciendo que Linq to SQL se pueda usar solo con SQL Server. El Entity Framework será el ORM de elección para multiple data providers.
Desafortunadamente, the Entity Framework seems not quite ready for prime time.
Así que depende de a quién le parezca. ¿Crees en las especulaciones (y solo son especulaciones) de muchos bloggers que dicen que Linq to SQL está realmente muerto y enterrado, o crees que gente como Damien Guard de Microsoft, que dice Linq to SQL has a long life ahead of it?
El capítulo de muestra de nerddinner escrito por ScottGu utiliza Linq-To-SQL, no respalda LINQ-to-SQL, pero tampoco promociona LINQ-To-Entities. Con ViewModel (Stephen Walther tiene una buena publicación sobre esto) & el patrón de repositorio, LINQ-To-SQL es perfecto para desarrollar aplicaciones ASP.NET MVC
¿Puedes proporcionar un enlace a la publicación de Stephen? –
Dos enlaces: http://stephenwalther.com/blog/archive/2009/02/27/chapter-5-understanding-models.aspx http://stephenwalther.com/blog/archive/2009/02 /27/chapter-5-understanding-models.aspx – indyfromoz
La única razón por la que las muestras se escribieron con LINQ-to-SQL es porque configurarlo es rápido y simple.
De lo contrario, puede usar cualquier ORM que se adapte a usted, ya sea EF o NHibernate o lo que sea.
En mi opinión, Linq to Entity no es un buen candidato por el momento. Una de las cosas que no me gusta de Linq To Entity es la falta de carga lenta, lo que me llevó a la pared cada vez que escribía mis repositorios. Creo que eso fue lo que me mató. La otra cosa es todo el problema con adjuntar y separar entidades que están siendo utilizadas por múltiples instancias del contexto del objeto. Ese fue otro asesino para mí, que resultó en una gran cantidad de piratería tratando de recrear relaciones de entidades, etc. Francamente, creo que una mejor cosa que hacer sería esperar la próxima versión de este marco. Creo que las cosas buenas están por venir :)
Personalmente, me gustaría empezar a acostumbrarme al Entity Framework ahora. Dado que tiene más características, es independiente del proveedor y se está desarrollando (tal vez) de manera más agresiva. Las dos quejas más comunes que escucho son la falta de POCO y la falta de carga lenta. Parece que ambos se tratan en .NET 4.0 http://blogs.msdn.com/adonet/archive/2009/05/28/poco-in-the-entity-framework-part-2-complex-types-deferred-loading-and-explicit-loading.aspx
Además de ser potencialmente más rápido (para empezar con) o más simple, no estoy seguro de cualquier particular, ventaja de utilizar LINQ a SQL, en el largo plazo. ¿Alguien sabe de alguna?
Lazy Loading es posible, pero no solo explícitamente –
Linq-to-SQL es una gran tecnología y muy fácil de usar, por lo que está muy bien orientada a demostraciones, y es una opción perfecta para proyectos más pequeños y directos, donde tienes más o menos 1 : 1 asignación de sus tablas en SQL Server a sus objetos en la memoria.
Y esas son las limitaciones más restrictivas de LINQ to SQL:
Si eso está bien Contigo, ¡adelante y use Linq-to-SQL! Por supuesto, MS todavía está agregando características y corrigiéndolas para .NET 4.0, no está muerto por una posibilidad remota.
Entity Framework en su versión v1 disponible ahora tiene algunas verrugas, como otros carteles han mencionado con razón (sin soporte de POCO, sin enfoque de "diseño de dominio primero" y muchos otros). ¡Pero el conjunto de características de EF v4 parece muy convincente, y le dará una oportunidad a Linq-to-SQL por su dinero!
Las principales ventajas para EF frente a Linq-to-SQL en un entorno empresarial son su independencia de base de datos (puede conectarlo a Oracle, Firebird, DB2, muchos otros) que pueden ser cruciales y su capacidad para presentar usted con un modelo de objetos que se ve bastante diferente del modelo de almacenamiento físico en la base de datos (en virtud de la asignación entre la capa conceptual y la capa de almacenamiento físico).
Entonces, realmente se trata de lo que necesita: ¿necesita una forma rápida de comenzar (demostraciones, aplicaciones más simples)? Entonces, su elección es claramente de Linq a SQL (al menos por ahora) o ¿necesita un enfoque de mapeo flexible contra un backend que no sea SQL Server? entonces su elección será Entity Framework.
Marc
Microsoft ha dicho que todavía admitirán LINQ to SQL, por lo que no está muerto. –
Sí, Microsoft dice esto, pero nadie creía –
Luego lo demostraron haciendo un montón de cambios en Linq a SQL en .NET 4.0: http://damieng.com/blog/2009/06/01/linq-to- sql-changes-in-net-40 –