Vaut-il mieux créer des classes Model ou s'en tenir à une classe d'utilitaires de base de données générique?

Question

Nous avons en interne une classe utilitaire simple pour nos appels de base de données (un wrapper léger autour d'ADO.NET), mais je pense à créer des classes pour chaque base de données/objet. Serait-il intelligent de le faire, ou cela ne serait-il bénéfique que si nous utilisions le framework MVC complet pour ASP.NET?

Nous avons donc ceci:

SQLWrapper.GetRecordset(connstr-alias, sql-statement, parameters); 
SQLWrapper.GetDataset(connstr-alias, sql-statement, parameters); 
SQLWrapper.Execute(connstr-alias, sql-statement, parameters); 

Pensée de le faire:

Person p = Person.get(id); 
p.fname = "jon"; 
p.lname = "smith"; 
p.Save(); 

ou pour un nouveau record -

Person p = new Person(); 
p.fname = "Jon"; 
p.lname = "Smith"; 
p.Save(); 
p.Delete(); 

Serait-ce intelligent, ou serait-il exagéré? Je peux voir l'avantage pour la réutilisation, le changement de base de données, et la maintenance/lisibilité.

Answer 1

Cette question est chargée, conception pilotée par les données par rapport à la conception pilotée par domaine. Pour toute application ayant un bon comportement, la conception pilotée par domaine devrait être préférée. Les rapports, ou les applications utilitaires ont tendance à mieux fonctionner (ou sont plus rapides à développer) avec la conception pilotée par les données.

Ce que vous demandez, c'est «est-ce que mon entreprise devrait changer fondamentalement la façon dont nous concevons notre code». En tant que monstre de domaine, ma réaction intestinale est de crier oui. Cependant, par la nature simple de votre question, je ne suis pas certain que vous compreniez parfaitement la portée du changement que vous proposez. Je pense que vous devriez en parler davantage à votre équipe. Obtenez un peu de littérature, comme Evan's DDD livre, ou le free foundations ebook, et alors vous serez dans une meilleure position pour juger dans quelle direction vous devriez aller.

Answer 2

MVC n'est pas le seul modèle de conception pour le Web, mais il est utile. Adopter juste le 'M' paiera des dividendes, à mon avis, même si vous ne pouvez/ne voulez pas adopter le 'V' ou le 'C'.

Answer 3

Pour moi, il semble que vous essayez de faire ce que LINQ peut déjà faire pour vous. Si vous êtes coincé dans un cadre plus ancien dans lequel vous ne pouvez pas utiliser cela, je vous suggère d'utiliser Subconic (http://subsonicproject.com/) au lieu de devoir créer manuellement tous ces objets de modèle à la main.

J'ai eu un projet où j'étais dans une situation similaire et j'ai changé de subsonique à mi-chemin avec des résultats fantastiques. Développement plus rapide et beaucoup plus facile à lire/utiliser du code.

Answer 4

L'approche que vous discutez est considérée comme une bonne par beaucoup de gens, moi inclus! Apprendre cette approche exigera quelques efforts, mais ne vous laissez pas décourager!

Qu'en est-il simplement d'essayer un petit projet avec LINQ to SQL? Peut-être trouver un nice reference project sur google code, et d'étudier comment les autres ont travaillé avec elle.

C'est un outil simple qui vous permettra de vous familiariser avec certains problèmes liés à la mise en correspondance d'objets avec des bases de données.

Vous pourrez alors en avoir une idée, et décider si cela vaut la peine d'apprendre.

Il y aura de nouveaux concepts pour saisir et d'expérimenter, des choses comme:

• Unité de travail: Lorsque vous exécutez Enregistrer et Supprimer etc, un ORM a tendance à ne pas le faire immédiatement, alors que un jeu d'enregistrements DAL sera basé. Cela peut être surprenant, vous devrez donc en apprendre un peu plus à ce sujet. Lisez sur le modèle de l'unité de travail pour obtenir une compréhension de cela.
• Les opérations en bloc représentent un problème avec OR/M. Un lecteur de données peut parcourir efficacement des milliers de lignes, mais avec un ORM, vous devez faire attention lorsque vous travaillez avec de grands lots d'objets. Encore une fois, un à lire.
• Associations semblent bonnes quand on peut faire des choses comme customer.Orders.Count mais ils sont aussi la cause de nombreux problèmes. Vous devrez trouver des pratiques sécuritaires à suivre lorsque vous travaillez avec des associations.

... pour n'en nommer que quelques-uns.

Pour commencer, ne vous inquiétez pas de l'héritage et d'autres choses, commencez simplement par des entités simples qui correspondent aux tables. Essayez de les utiliser de la même manière que vous utiliseriez votre DAL existant. Puis commencez à expérimenter avec des associations. Ensuite, essayez peut-être de mettre plus de comportement dans vos entités. Si vous commencez à aimer cela, et pensez que vous avez besoin de plus de fonctionnalités, pensez à essayer un ORM plus riche en fonctionnalités, tel que Lightspeed ou NHibernate.

Espérons que cela aide!