Souhaitez-vous utiliser LINQ to SQL pour les nouveaux projets?

Question

Je suis enquêtait sur ce que la couche de données à utiliser pour un nouveau projet basé sur le Web, je suis la conception et je suis très désireux de voir intégrer LINQ to SQL. Son soutien apparente simplicité, la flexibilité et le concepteur vraiment appels et le lien dans SQL Server implicite est très bien.

Cependant, il a été annoncé récemment que LINQ to SQL va prendre un siège arrière à Entity Framework maintenant qu'il a été transmis à l'équipe de ADO.NET ( http://blogs.msdn.com/ adonet / archive / 2008/10/29 / mise à jour sur-LINQ-to-sql-et-LINQ à entités roadmap.aspx ). Bien sûr, il sera pris en charge à l'avenir, mais il est peu probable qu'il verra beaucoup plus de travail de développement.

Dans cet esprit, vous me recommandons d'utiliser cette technologie pour mon projet ou est-il la peine soit sélectionner une autre ORM (NHibernate?) Ou le codage manuellement un DAL générique?

Le projet lui-même est ASP.NET et SQL Server 2005/2008 base et éventuellement utiliser MVC, même si elle est encore en version bêta. Il est un projet personnel, la base de données ne sera pas trop complexe et il sera principalement utilisé comme prototype pour regarder la technologie future .NET. Je fonderaient des projets futurs sur ce que j'appris de celui-ci, donc les choix que je fais affectera-t-grandes solutions à venir.

Et oui, je me rends compte que Microsoft va probablement faire ressortir une toute nouvelle technologie de demain d'accès aux données de toute façon! ;)

Answer 1

Eh bien, il est la plupart du temps couvert de réponses ici (quelques points de vue intéressants aussi bien) déjà, mais je vais le dire encore une fois de toute façon ..

LINQ to SQL (L2S) est très polyvalent, mais il se sent un peu trop basique de mon point de vue. Dans la plupart des cas, il fait un bon travail à faire des choses simples, mais dès que vous demandez un peu plus, il devient cher. Ce n'est pas du tout une mauvaise chose. Je pense en fait LINQ to SQL suppliments fait Entity Framework bien.

Prenez Paging Auto avec LinqDataSource par exemple. Si vous ne spécifiez pas l'ordre par / groupe il est alors tout à fait économique. Jeter la commande ou le regroupement dans le mélange et vous commencez à obtenir un pic de performance (devient très bavard). Ensuite, vous avez à peu près écrire votre propre implémentation d'échange (ce qui est pas très difficile, je l'avoue).

Je serai le premier à admettre que L2S a l'avantage sur Entity Framework en termes de la qualité du T-SQL généré (je devrais, car L2S est construit spécifiquement pour effectuer des requêtes SQL Server) et sur le plan conceptuel et symantically, une grande partie de LINQ to SQL est similaire à EF, mais où vous frappez le mur est en expansion des besoins et compte pour les besoins de mise en œuvre plus complexes.

Si je devais recommencer à zéro et choisissez de consacrer du temps de développement personnel, je choisirais Entity Framework. Il est intéressant, je travaille sur un projet au moment qui utilise L2S et il est conçu à l'échelle gérer des charges lourdes nad, mais quand nous avons touché quelques-unes des exigences plus « créatifs », nous sommes souvent contraints de développer SQL métal (par exemple plusieurs à plusieurs relations).

.. bref .. je l'aborde ainsi:

a) apprendre LINQ to SQL comme une intro (aux modèles ORM de Microsoft et de la technologie) .. il vous permet de vous familiariser avec la plupart des fondamentaux qui sont partagées avec Entity Framework, et un avant-goût de l'interrogation de style LINQ (un goût acquis si vous avez un arrière-plan en T-SQL)

b) une fois que vous avez une poignée sur LINQ to SQL, je vous recommande de sauter vers Entity Framework pour apprendre les avantages supplémentaires (eSQL etc)

c) Mettre en œuvre un projet de validation de concept dans les deux et comparer les résultats.

Answer 2

Choisissez NHibernate. Il reste un certain temps comme un concept ou ORM réelle. Il sera donc utile d'apprendre les deux.

Answer 3

OMI, cette chose était vraiment soufflé hors de proportion.

Microsoft n'a pas dit que LINQ to SQL serait mort. Ils ont indiqué que plus il serait fusionné dans Entity Framework.

Je me concentrerais sur l'utilisation Entity Framework comme une solution, sachant que la plupart des LINQ to SQL seront roulées en elle.

Il n'y a vraiment pas beaucoup de différence en ce moment de toute façon. La plus grande plainte est que le Entity Framework n'est pas léger. Est-ce que vraiment d'importance tant que vous avez une bonne séparation entre vos niveaux?

Answer 4

L2S est, à mon humble avis, parfaitement bien la façon dont il est et comme vous l'avez dit, ne va nulle part. La société pour laquelle je travaille a fait notre norme d'accès aux données et nous l'utilisons pour tout, de petits 5 applications de niche utilisateur à utilisateur 1000+ des applications d'entreprise avec d'excellents résultats.

Answer 5

Consultez SubSonic:

http://subsonicproject.com/

Answer 6

Je pense que les objectifs du EDM notre plus grand que ceux de LINQ to SQL. Si vous êtes à la recherche pour un simple ORM alors je pense que LINQ to SQL est le chemin à parcourir. Si vous envisagez de construire dans les classes qui ont une structure d'héritage par rapport aux tables de base de données qui ont une structure relationnelle et faire d'autres applications avancées, alors EDM pourrait être un bon choix.

Answer 7

Il convient de mentionner que ce site est construit en utilisant LINQ to SQL. Jeff a parlé de l'utiliser sur le podcast StackOverflow.

Answer 8

L2S est une technologie impressionnante, et je ne retournerai jamais à l'ancienne ADO.

Mais comme vous l'avez mentionné, il prend une banquette arrière à L2E. L2S est plus que capable et je l'ai ont fait de nombreuses applications avec et ont été très heureux. Mais entendre qu'il ne sera plus avancé mis un couteau dans mon côté. Je suis donc allé vérifier L2E et il est presque la même chose quand il s'agit de SQL interaction, et à bien des égards je trouve plus facile, sans parler plus efficace avec sa gestion de la relation. Avec ces similitudes, il semble logique de choisir L2E.

J'ai écrit un post sur le commutateur et faire la comparaison des deux cadres: http://naspinski.net/post/Getting-started-with-Linq-To-Entities.aspx

Je peux presque garantir que vous serez heureux avec l'un de ces cadres, ils sont une aubaine pour le développement. La prévention de la simplicité et l'erreur est sans pareil. Personnellement, je penchez à L2E comme il sera développé de façon plus agressive thatn L2S.

Answer 9

J'utilise L2S fortement sur mon projet Web en cours et je crois que le plus grand raccrochage, vous trouverez la documentation est en conflit au sujet de la meilleure façon de faire du développement de la base de données n-tiers.

D'abord et avant tout ce que vous devez réaliser Upfront, objets DataContext sont destinés à durer aussi longtemps que l'unité de travail , période. De plus, DataContext ce sont apatrides. Une fois que vous venez à bout de ces deux principes, en utilisant LINQ dans un environnement multi-tiers commence à bien fonctionner.

Par contre, vous verrez un certain nombre de personnes recommandant des moyens très très très mauvais pour utiliser LINQ. Ne jamais faire votre DataContext statique, c'est une erreur que j'ai fait très tôt et il a fait des merveilles jusqu'à ce qu'il ne marchait pas, il était absolument horrible avec passage des données incorrectes dans les différentes sessions, etc. En termes simples, cela est peut-être le plus grand plus gigantesque sans aucun d'utiliser LINQ et doit être écrit en gros caractères gras dans tous les documents. En outre, la persistance d'un DataContext dans une variable de session est une idée tout aussi mauvais.

Le seul autre grand méchant je suis tombé avec LINQ est lorsque vous faites une mise à jour déconnecté, vous devez utiliser le même DataContext à travers tout l'appel. Par exemple:

    public static void UpdateUser(UserLibrary.User user) {
        using (UserLibraryDataContext dc = new UserLibraryDataContext(_conStr))
        {
            UserLibrary.User newUser = (from user2 in dc.Users where user2.UserID == user.UserID select user2).FirstOrDefault();
            newUser.Email = user.Email;
            newUser.FirstName = user.FirstName;
            newUser.LastName = user.LastName;
            dc.SubmitChanges();
        }        

Vous ne pouvez pas passer simplement dans un utilisateur créé dans une autre datacontext et attendre mise à jour fonctionne, sauf si vous définissez DataContext.ObjectTrackingEnabled = false, que je ne recommanderais pas. Au lieu de cela, dans le même DataContext vous devez récupérer l'objet existant, mettre à jour ses valeurs, puis soumettre que des changements. Gardez toutes les tâches comme dans le même DataContext.

Je recommande L2S cependant, une fois que vous obtenez sur quelques questions tatillonne (comme ci-dessus), il est une grande technologie et definatly un gain de temps. Je recommande de faire cependant une enveloppe mince autour de votre DAL, de sorte que vous pouvez changer facilement. Je considère (pour des raisons économiques) le portage d'une partie de mon code à utiliser OpenAccess ORM -> MySql pour une partie de mon accès aux données, et d'une couche correctement définie, cette tâche ne devrait me prendre quelques heures.

Answer 10

Je suis d'accord avec Echostorm. L2S est bon pour vos besoins. Et il est assez facile de travailler avec ...

Answer 11

Si vous concevez votre application correctement et d'isoler la couche de vos accès aux données bien, vous devriez aller avec L2S. D'après ce que je déduis de votre poste, ce n'est pas un grand projet, donc L2S devrait répondre à vos besoins très bien, alors que le bon vieux ADO.NET est juste un non-non, et Entity Framework, est ... juste ne l'utilisez pas , D'accord? Quoi qu'il en soit, si vous isolez votre DAL bien, vous pouvez échanger L2S à autre chose à l'avenir si le projet se développe. et même si L2S ne va nulle part, il ne va nulle part. MS cessé d'investir dans, mais il ne va pas devenir désapprouvée ou quelque chose, il est donc encore un investissement sûr. Sinon, vous devez évaluer NHibernate, qui est simple et mature.