Devrais-je commencer à utiliser LINQ To SQL?

Question

J'utilise actuellement NetTiers pour générer ma couche d'accès aux données et ma couche de service. J'utilise NetTiers depuis plus de 2 ans et je l'ai trouvé très utile. À un moment donné, j'ai besoin de regarder LINQ pour que mes questions soient ...

1. Quelqu'un d'autre est-il passé de NetTiers à LINQ en SQL?
2. Ce changement a-t-il été une bonne ou une mauvaise chose?
3. Y a-t-il quelque chose que je devrais être au courant?
4. Recommanderiez-vous ce commutateur?

En gros, toute idée serait la bienvenue .

Answer 1

1. Non
2. voir le n ° 1
3. Méfiez-vous des frais généraux d'abstraction. En outre, il est très basé sur SQL Server dans son état actuel.
4. Utilisez-vous SQL Server, alors peut-être. Si vous utilisez actuellement LINQ pour d'autres tâches telles que des données XML (géniales), des données d'objet, des jeux de données, alors vous devriez opter pour une syntaxe de données uniforme pour toutes. Comme lagerdalek mentionné si cela n'a pas été cassé, ne le faites pas répare le. En regardant rapidement .NETTiers Application Framework, je dirais que si vous avez déjà un investissement avec cette solution, elle semble vous fournir bien plus qu’une simple couche d’accès aux données et vous devez vous en tenir à celle-ci.

De mon expérience, LINQ to SQL est une bonne solution pour les projets de petite à moyenne taille. C'est un ORM qui est un excellent moyen d'améliorer la productivité. De plus, devrait vous donner une autre couche d’abstraction qui vous permettra de changer la couche en dessous pour autre chose. Le concepteur de Visual Studio (et je crois aussi que VS Express) est très simple et facile à utiliser. Il vous donne l’édition courante des mappages d’objets par glisser-déposer et par propriétés.

@ Jason Jackson - Le concepteur vous laisse ajoutez des propriétés à la main, mais vous devez spécifier les attributs de cette propriété. Une fois cette opération effectuée, il peut s'écouler 3 minutes de plus que le glissement initial de la table dans le concepteur. Ce n'est toutefois nécessaire qu'une fois par modification dans la base de données. lui-même. Ce n’est pas très différent des autres ORM, mais vous avez raison de dire qu’ils pourraient le faciliter beaucoup plus facilement et ne rechercher que les propriétés qui ont changé, voire même mettre en œuvre un type d’outil de refactoring pour de tels besoins.

Ressources:

• Pourquoi utiliser LINQ to SQL?
• Scott Guthrie sur LINQ to SQL
• 10 conseils pour améliorer les performances de vos applications LINQ to SQL
• Mise à jour des performances de LINQ vers SQL et Visual Studio 2008
• Comparaisons des performances LINQ vers SQL / ADO / C #
• Vue d'ensemble de LINQ to SQL 5 minutes

Notez que le LINQ parallèle est en cours de développement pour permettre beaucoup de meilleures performances sur les machines multicœurs.

Answer 2

J'ai essayé d'utiliser Linq en SQL sur un petit projet, pensant que je voulais quelque chose que je pourrais générer rapidement. J'ai rencontré beaucoup de problèmes chez le designer. Par exemple, chaque fois que vous devez ajouter une colonne à une table, vous devez en principe supprimer et rajouter la définition de la table dans le concepteur. Si vous avez défini des propriétés sur la table, vous devez redéfinir ces propriétés. Pour moi, cela a vraiment ralenti le processus de développement.

LINQ to SQL lui-même est agréable. J'aime beaucoup l'extensibilité. S'ils peuvent améliorer le concepteur, je pourrais l'essayer à nouveau. Je pense que le framework bénéficierait d'un peu plus de fonctionnalités destinées à un modèle déconnecté tel que le développement web.

Découvrez Les articles de blog de la série LINQ to SQL de Scott Guthrie pour de superbes exemples d'utilisation.

Answer 3

NetTiers est très utile pour générer un DAL lourd et robuste, et nous l’utilisons en interne pour les librairies principales et les frameworks.

Comme je le vois, LINQ (dans toutes ses incarnations, mais plus précisément comme je pense que vous demandez à SQL) est fantastique pour un accès rapide aux données, et nous l’utilisons généralement pour des cas plus agiles.

Les deux technologies sont assez inflexibles pour changer sans régénération du code ou de la couche dbml.

Cela étant dit, correctement utilisé LINQ 2 SQL est une solution assez robuste, et vous pourriez même commencer à l’utiliser pour des développements futurs en raison de sa facilité d’utilisation, mais je ne jetterais pas votre DAL actuel pour cela - si cela se produit. n'est pas cassé ...

Answer 4

D'après mon expérience, l'utilisation de linq vous permet d'accomplir les tâches plus rapidement, mais les actions effectives sur la base de données sont plus lentes.

Alors ... si vous avez une petite base de données, je vous prierais d'y aller. Sinon, j'attendrais quelques améliorations avant de changer

Answer 5

J'utilise LINQ to SQL sur un projet assez volumineux (environ 150 tables) et cela fonctionne très bien pour moi. Le dernier ORM que j'ai utilisé était IBatis et cela a bien fonctionné, mais il a fallu beaucoup de travail pour faire vos cartographies. LINQ to SQL fonctionne très bien pour moi et s’est révélé jusqu’à présent très facile à utiliser. Il y a certainement des différences à surmonter lors de la transition, mais je recommanderais de les utiliser.

Remarque secondaire, je n'ai jamais utilisé ni lu à propos de NetTiers, je ne minimiserai donc pas son efficacité, mais LINQ to SQL en général s'est avéré être un ORM extrêmement viable.

Answer 6

Notre équipe utilisait autrefois NetTiers et le trouvait utile. MAIS ... plus nous l’utilisions, plus nous trouvions de maux de tête et de points douloureux. Par exemple, chaque fois que vous modifiez la base de données, vous devez générer à nouveau le DAL avec CodeSmith, ce qui implique:

• générer de nouveau des milliers de lignes de code dans 3 projets distincts
• régénérer des centaines de procédures stockées

Peut-être existe-t-il d'autres moyens de le faire, mais c'est ce que nous devions faire. La régénération du code source était ok, effrayant, mais ok. Le vrai problème est venu avec les procédures stockées. Il n'a pas nettoyé les procédures stockées inutilisées, donc si vous avez supprimé une table de votre schéma et reconfiguré votre DAL, les procédures stockées de cette table ne sont pas supprimées. En outre, cela est devenu un casse-tête pour les scripts de modification de base de données, dans lesquels nous devions comparer l'ancienne structure de la base de données à la nouvelle et créer un script de modification pour mettre à jour les installations client. Ce script pourrait parcourir des dizaines de milliers de lignes de code SQL et s’il était invariablement causé par un problème d’exécution, c’était très pénible de le résoudre.

Puis la lumière s’alluma, NHibernate en tant que ORM. Il a certainement un temps de montée en puissance mais cela en vaut la peine. Il y a énormément de soutien, alors si vous devez faire quelque chose, c'est plus que probable que cela a déjà été fait auparavant. Il est extrêmement flexible et vous permet de contrôler chaque aspect et d’autres. Il devient également plus facile et plus facile à utiliser. Fluent Nhibernate est un bon moyen de se débarrasser des fichiers de mappage xml nécessaires et NHibernate Profiler fournit une excellente interface permettant de voir ce qui se passe dans les coulisses afin d’accroître l’efficacité et de supprimer les redondances.

Passer de NetTiers à NHibernate a été douloureux, mais dans le bon sens. Cela nous a obligés à adopter une meilleure architecture et à réévaluer les besoins fonctionnels. NetTiers a fourni des tonnes de code d'accès aux données, identifiez cette entité par son identifiant, cette autre entité par sa clé étrangère, obtenez une liste t et vlist de ceci et cela, mais la plupart étaient inutiles et inutilisées. NHibernate avec un référentiel générique et des référentiels personnalisés uniquement lorsque cela est nécessaire a permis de réduire les tonnes de code inutilisé, ainsi que la lisibilité et la fiabilité.