Quelle est la meilleure approche de l'application C# de base de données multi-utilisateur?

Question

Je voudrais savoir quelle est la meilleure méthode pour développer une application C# multi-utilisateur en utilisant le SQL Server2005 comme base de données. C'est ce que j'ai à l'esprit:

1. en utilisant nhibernate ou openacces orm de telerik.
2. linq
3. en utilisant des wrappers. toutes les données des tables sont chargées dans les objets correspondants (au démarrage) et, à partir de ce point, ne suppriment que les transactions de mise à jour & affectant la base de données.
4. ...

Je l'ai regardé outils ORM, mais à mon avis, ils génèrent beaucoup de code et je ne sais pas si il est nécessaire.

Quelle est la meilleure solution compte tenu des changements futurs dans l'application? Si je choisissais la 3ème option, comment puis-je m'assurer qu'un seul utilisateur modifie une ligne dans une table (comment puis-je verrouiller une ligne de table qui est en cours de modification)? Toute suggestion ou matériel de lecture aidera! Merci!

Answer 1

Épargnez-vous beaucoup d'efforts et de temps et utilisez un ORM. Pour vous aider à décider lequel, il y a beaucoup d'informations/opinions sur le web (et StackOverflow!) Sur lequel utiliser, mais cela dépendra de vos besoins (que vous n'avez pas décrits). J'aime Linq-to-SQL pour les petites/moyennes applications. C'est rapide et facile et presque efficace. Pour les applications plus volumineuses, cela dépendra des types de transformations de données et de la conception que vous avez en tête, mais Linq-to-Entities ou nHibernate sont probablement les plus appropriés.

Answer 2

S'il s'agit d'un multi-utilisateur, NE faites PAS # 3. Le but d'un SGBD est de gérer les aspects multi-utilisateurs pour vous. Tout, depuis les transactions jusqu'aux droits d'accès, est intégré. Il est difficile d'aller dans le sens d'imiter cela dans votre code. Dans le passé, certains "moteurs" comme le BDE de Borland et MS Access l'ont fait. Le résultat final est que vous finissez par faire face à de petites choses comme la corruption de données et les erreurs de cohérence.

Peu importe que votre base de données s'agrandisse, le démarrage prendra exponentiellement plus de temps. Nous restons généralement à l'écart des outils ORM pour un certain nombre de raisons, principalement des problèmes de fonctionnalité/bénéfice/sécurité. Bien sûr, nous maîtrisons parfaitement SQL et pouvons tirer parti des fonctionnalités spécifiques qu'un serveur db donné peut offrir, ce que la plupart des ORM ne peuvent pas faire. Nous avons également tendance à modifier les requêtes en fonction des mesures de performances après la sortie du produit, ce qui obligerait à recompiler une application pour la plupart des ORM. En restant loin de cela, nous pouvons laisser les DBA de production faire leur travail. Cela peut ou peut ne pas être votre préoccupation.

Cela dit, beaucoup d'équipes de développement aiment et utilisent avec succès celles dont vous avez parlé. Je dirais de passer Linq-to-SQL en faveur d'Entity Framework si vous suivez cette route. Linq-to-SQL a presque été remplacé par EF.

Answer 3

Il y a des centaines de façons de résoudre cela, mais ne négligez pas ORM. Le Entity Framework de Microsoft s'améliore à chaque révision. Les frameworks 4.0 bits sont plutôt bons et jouent extrêmement bien avec LINQ. En ce qui concerne le code généré par rapport au vôtre, essayez quelque chose comme Entity Spaces ... Vous avez un contrôle total sur la façon dont le code est généré et la couche d'accès aux données est extrêmement puissante et flexible (pour ne pas mentionner très facile à utiliser).Il joue aussi bien avec LINQ.

J'ai écrit beaucoup de code d'accès aux données au cours des années. Au début, les outils ORM étaient approximatifs et laissaient beaucoup à désirer. Ces outils ont subi de nombreuses itérations depuis et sont devenus indispensables à mon avis. Je ne peux pas imaginer écrire une routine après une routine qui fait le même CRUD de base. Je l'ai fait pendant des années et j'ai passé beaucoup de temps à corriger le SQL codé en dur et je me suis juré de l'éviter à tout prix à partir de maintenant. En ce qui concerne les problèmes de concurrence/verrouillage, c'est une question à part entière. Il y a plusieurs façons de fournir le verrouillage (les catégories principales étant optimistes et pessimistes). Chacun a ses avantages et ses inconvénients.