application existante, puis-je commencer à utiliser linq-to-sql? des conseils sur l'intégration?

Question

J'ai une application web existante qui a une couche de données et un bll qui appelle la couche de données. La couche de données est ado.net qui appelle les procédures stockées.

J'ai créé un autre projet dans vsnet pour linq-to-sql, j'ai déplacé toutes mes tables. Est-ce qu'il serait sage de commencer à utiliser linq ou devrais-je passer le temps et réécrire toute la logique db dans linq juste pour ne pas avoir de problèmes avec 2 couches de données!

Answer 1

À moins que votre couche de données actuelle ne soit cassée pour une raison quelconque, ne commencez pas simplement à en implémenter une nouvelle, juste parce que vous le pouvez. Bien que si actuellement la couche datalogique consiste à utiliser des procédures stockées et que cela devient fastidieux à maintenir, passer à L2S (ou à tout autre OR/M d'ailleurs) pourrait être une raison valable. Juste ne pense pas que ce sera juste une question de glisser quelques colonnes sur une toile et d'être fait. Dépendante s'il y a une logique dans les sprocs, la logique doit exister quelque part ...

Je dirais jusqu'à ce que vous puissiez justifier les coûts de commutation de votre datalayer entièrement, respectez votre implémentation actuelle.

Answer 2

S'il n'est pas endommagé, ne le réparez pas. Pourquoi voudriez-vous réécrire complètement votre couche de données fonctionnant parfaitement? ADO.NET + procédures stockées est un excellent choix. Garde le. En même temps, vous pouvez commencer à jouer avec LINQ.

Quoi qu'il en soit, vous aurez besoin de pratique avec LINQ pour voir ce qu'il peut faire et ce qu'il ne peut pas faire avant de pouvoir décider de la nouvelle architecture de la couche de données. Il existe certaines situations que LINQ ne peut gérer directement, vous devrez donc utiliser des astuces ou remplacer l'implémentation par défaut par vos propres requêtes. À la fin de la journée, vous avez peut-être décidé, cela n'en valait pas la peine.

Ma suggestion est d'acquérir une certaine expérience avec elle séparément et ne pas commencer à tout réécrire complètement juste parce que LINQ est cool.

Answer 3

Veuillez être clair: il y a une différence majeure entre Linq et LinqToSql. Linq est génial et vous devriez l'utiliser si possible. LinqToSql n'est pas grand et a de nombreux problèmes:

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

The drawbacks of adopting Linq To Sql

Pour utiliser LINQ, vous avez besoin d'un ORM de quelque sorte. Vous disposez de nombreuses options pour les ORM dans le monde .NET. Si vous aimez ce que propose LinqToSql, vous pouvez être plus à l'aise avec SubSonic. À long terme, NHibernate est le meilleur choix pour un ORM .NET en ce moment. J'ai écrit beaucoup plus sur le choix d'un ORM .NET ici:

.NET and ORM - Decisions, decisions

En fin de compte, il n'y a aucune raison que vous ne pouvez pas avoir deux ou plusieurs technologies de couche de données dans la même application. Il y a de bonnes raisons de ne pas le faire et il faut donc éviter autant que possible.

De plus, voici une écriture convaincante en place contre l'utilisation des procédures stockées:

Stored procedures are bad, m'kay?