.NET et couches de base de données

Question

Lorsque j'ai travaillé pour la dernière fois en programmation, nous essayions de passer de DataReaders et de l'API ADO.NET traditionnelle à Object Relational Mapping (ORM). Pour cela, nous avons généré un DataContext de notre base de données via sqlmetal. Il y avait alors une couche de données mince qui faisait DataContextprivate, et tout code ayant besoin d'accéder à la base de données devait utiliser une méthode public dans cette couche de données minces. Ces méthodes étaient essentiellement des procédures stockées; ils effectueraient des requêtes sur la base de données via LINQ to SQL.

Est-ce une approche courante aujourd'hui? Je veux dire, est-ce que tous ceux qui utilisent le framework .NET 3.5 exécutent vraiment sqlmetal dans leur processus de construction, ou quoi? Cela ressemblait presque à un hack à l'époque. Fondamentalement, je voudrais savoir si LINQ to SQL et sqlmetal est ce à quoi s'attendre si je vais écrire un DAL aujourd'hui dans un magasin .NET 3.5 qui n'emploie pas un tiers, open- source ORM.

Answer 1

Votre approche est bonne. J'utilise actuellement les services Astroria (ADO.NET Data Services). Il y avait une bonne introduction dans MSDN Magazine à ce sujet.J'ai aussi aimé le nouveau PLINQO (nécessite CodeSmith Tools cependant). C'est très lisse à mon avis.

Lorsque j'ai une telle DAL (couche de service), je viens de consommer ce service à partir de mon application client (Silverlight ou ASP.NET MVC).

Answer 2

Je pense que cela dépend de votre utilisation, mais je dirais avec une couche de données si mince que vous avez expliqué que ce serait votre DAL. La plupart des projets construiront une autre couche au-dessus de cela principalement pour la logique éditer/créer et peut-être une certaine logique d'assemblage pour obtenir.

Pour la plupart de mes projets, je le conçois comme ceci.

Repository détient l'instance de DataContext et expose quelques add de base/supprimer des méthodes
ProductRepository: Repository expose les requêtes générales (IQueryable)
StoreService utilise une instance de différents référentiels comme ProductRepository, SalesRepository et gère toute logique pour créer quelque chose comme un produit.

donc quelque chose comme ...

StoreService.CreateProduct(/* properites */) 

Cela reviendrait une sorte de classe de résultats.

Answer 3

Il est toujours considéré comme la meilleure pratique d'avoir une sorte de couche d'accès aux données. La question de savoir si cela est le mieux réalisé avec un ORM est un sujet très débattu. Il y a une faction qui soutient généralement que les ORM sont la voie à suivre. Une autre faction soutient que les procédures stockées et la base de données centrée sont la meilleure voie.

En outre, cela peut ne pas être exactement l'affiche que vous vouliez dire, mais similaire (et aussi celui de ma cabine)

http://download.microsoft.com/download/4/a/3/4a3c7c55-84ab-4588-84a4-f96424a7d82d/NET35_Namespaces_Poster_LORES.pdf

Answer 4

Ce site très utilise LINQ to SQL, prenez donc que vous volonté. Officiellement, Microsoft prend en charge Entity Framework sur LINQ to SQL en termes de nouveaux développements. Cependant, il y a un groupe vocal de personnes qui pensent EF is the wrong way to go. LINQ to SQL sera toujours là pendant un certain temps, et est un ORM très correct, si c'est quelque peu limitant en termes de backend DB que vous pouvez utiliser.

Je recommanderais LINQ comme un excellent point de départ pour votre ORM. Si vous avez besoin de mieux, regardez dans EF et/ou NHibernate.

Answer 5

"Est-ce une approche courante aujourd'hui? Je veux dire, est-ce que tous ceux qui utilisent le framework .NET 3.5 exécutent réellement sqlmetal dans leur processus de construction, ou quoi?"

Les personnes que je connais en utilisant le Framework 3.5 (et c'est à peu près tout le monde) - la grande majorité - utilisent toujours NHibernate. La version 2.0 est un très bon OR/M. J'ai commencé à l'utiliser sur un projet récent et il a considérablement réduit mon code d'accès aux données, au point que je ne veux plus utiliser quoi que ce soit dans le futur. Et l'API Fluent NHibernate fait des progrès pour les personnes qui n'aiment pas le mappage XML.

Answer 6

La meilleure couche de données est celle qui est simple et qui permet de faire le travail sans aucun sifflement. J'ai utilisé les technologies que vous avez mentionnées et écrites à leur sujet ici: The Only Pattern for Data Access is - There Are No Patterns for Data Access