Nouveau projet .NET 3.5: Quelle technologie DAL utiliser?

Question

Je prépare un nouveau projet Windows et je me demande quel type de technologie DAL utiliser. À l'origine, je recherchais quelque chose de plus simple pour ne pas perdre trop de temps à le construire. Mais je comprends aussi qu’il doit être efficace et évolutif à long terme.

Je prévois d’utiliser le client WPF (MVVM) et le service WCF sur un système à 3 niveaux.

Pour résumer toutes les technologies existantes que je connais bien:

Ensembles de données

PRO: Peut-être un peu démodé, mais très facile à utiliser et laisser la plupart des pièces être générées automatiquement pour vous. Un aspect puissant des jeux de données est la facilité de parcourir des données liées à travers les relations. D'une certaine manière, il est également déconnecté de la base de données et pourrait simplifier les mises à jour en prenant en charge les horodatages automatiquement. Inclut la validation.

CONTRA: Assez démodé. Certains les considèrent comme des objets métier / modèles réels, mais simplement comme un miroir de vos tables de données SQL. Les transmettre entre le service / client WCF peut s'avérer plus difficile que les objets métier créés par vous-même.

Enterprise Library 4.1 - Bloc d'accès aux données

PRO: Le DAL est magnifiquement mis dans un modèle d’usine. Il se charge de l'ouverture et de la fermeture de la connexion automatiquement. Très facile à utiliser pour la plupart. Il prend en charge les ensembles de données et les utilisateurs SQL normaux pour créer vos propres objets métier. Dans le cadre d’un cadre permanent, il peut être beaucoup plus efficace de l’utiliser avec le reste de la bibliothèque pour un produit final efficace.

CONTRA: ??

Linq to SQL

PRO: crée automatiquement les tables SQL en objets métier. Facile à créer. Théoriquement une très bonne façon de le faire.

CONTRA: Après avoir joué avec lui quand il est sorti, je l’ai trouvé floconneux et parfois instable. Il est déjà considéré comme une technologie morte après l'annonce par Microsoft qu'Entity Framework 4.0 - faisant partie de .NET 4.0 - sera le moyen recommandé par Microsoft. Seuls quelques correctifs de bogues sont attendus dans .NET 4.0, mais plus de plans d'extension de fonctionnalités.

Entity Framework 4.0

Je ne sais rien à ce sujet, mais seulement qu'il finira par remplacer tout le reste, comme sur .NET 4.0. Je suis aussi tenté de l'utiliser, mais comme il est toujours en version bêta, je ne serais pas capable d'y aller pour l'instant.

Je suis très tenté d'utiliser Enterprise Library 4.1 - Bloc d'accès aux données et de créer mes propres objets métier. Le gros problème est que la création du DAL prendra plus de temps. À moins que quelqu'un puisse me convaincre d'utiliser DataSets via le bloc d'accès aux données.

Quels sont vos commentaires et vos idées? Merci beaucoup, Kave

Answer 1

Vous avez mentionné Entity Framework dans le cadre du paramètre "contra". pour l'option Linq to SQL, mais vous devriez le considérer à la place de Linq to SQL - il fournit à peu près les mêmes fonctionnalités, mais plus. Pour les projets avec des bases de données plus petites, cela apporte certainement beaucoup pour son argent. Dans EF, il peut être difficile de gérer le contexte de bases de données plus volumineuses, et les modifications de schéma peuvent entraîner des dysfonctionnements, mais ces défis existent dans toute approche d'accès aux données.

Le plus gros problème pour EntLib, dans mon esprit, est que vous continuez à faire rouler vos propres objets de données. La bibliothèque d'entreprise enlève une grande partie du code de plomberie d'une simple "vieille école" L’implémentation ADO.NET, ce qui est bien, mais elle ne génère pas pour vous d’objets de données pouvant être utilisés immédiatement pour les requêtes LINQ.

Answer 2

Nous utilisions auparavant DataSets avec EntLib 4.1 Data Application Block.

Nous utilisons maintenant Entity Framework. Nous avons réussi à améliorer considérablement la productivité avec Entity Framework par rapport à EntLib 4.1. (Programmez la couche de données pour 80 tables en 10 heures au lieu de 80)

Entity Framework 4 est toujours en version bêta, mais s’il faut attendre beaucoup de temps avant que votre projet soit lancé, je choisirais EF 4. Vous bénéficiez de la productivité d’un ORM et de la souplesse d’utilisation de POCO (Plain Old Clr). Objets)

Answer 3

A. Vérifiez également NHibernate.

B. DataSet - le plus rapide et le plus facile, mais vous codez beaucoup.

Tout le reste - l'utilisation des outils ORM est très utile, mais l'utilisation de la hiérarchisation à trois niveaux pose de nombreux problèmes.

(le chargement paresseux est un problème à résoudre, car il génère de nombreuses grandes arborescences d’objectifs qui affectent les performances, la mise en cache n’est pas aussi intelligente que possible)

Donc, cela dépend de vos besoins principaux et du temps que vous souhaitez consacrer à l'étude d'EL / LINQ ou de NHibernate avant de commencer à coder, car il existe une courbe d'apprentissage avec ces outils.

Answer 4

La meilleure idée est d’avoir la possibilité d’utiliser les deux technologies en même temps. Comment peux-tu le faire? C'est très simple avec le modèle de référentiel. Au début, vous devez créer une interface IRepository générique. Quelque chose aime ça:

public interface IERepository<E>
{
    DbTransaction BeginTransaction();
    void EndTransaction();
    void Add(E entity);
    void Delete(E entity);
    int Save();

    ObjectQuery<E> DoQuery(string entitySetName);
    IList<E> SelectAll(string entitySetName);
    E SelectByKey(int Key);

    bool TrySameValueExist(string fieldName, object fieldValue, string key);
    bool TryEntity(ISpecification<E> selectSpec);

    int GetCount();
    int GetCount(ISpecification<E> selectSpec);
    int AddAndSave(E entity);

}

Je préfère Entity Framework. J'ai créé 3 projets sur cette base. Cela fonctionne très vite, en particulier les requêtes avec pagination. Donc, après que vous ayez besoin de créer la classe générique de base Repository avec les méthodes virtuelles qui implémentent l'interface IRepository. Et c’est tout.  Vous avez maintenant un moyen très rapide de créer DAl en écrivant un code simple comme ceci:

public class MonthRepository:Repository<Month>
{

}

Vous avez la possibilité de remplacer toutes les méthodes de la classe de base et de créer un accès à la base de données à l'aide de la procédure stockée dont vous avez besoin. Et vous pouvez le faire sans changer de code ailleurs. Vous retournerez toujours le même type d'entités mais vous les obtiendrez d'une autre manière.

En savoir plus sur http://www.codeproject.com/KB/database/ ImplRepositoryPatternEF.aspx

Answer 5

NHibernate présente le meilleur mélange global de fonctionnalités, de maturité et de support.

NHibernate, Entity Framework, enregistrements actifs ou linq2sql

Vous devez considérer le support Linq comme une priorité pour toute solution que vous envisagez et les deux premières options ci-dessus ne le prennent pas en charge.