Comment concevoir une Couche d'Accès aux Données de manière appropriée?

J'ai la suite de Couche d'Accès aux Données (DAL). Je me demandais si il est configuré correctement, ou si j'ai besoin de l'améliorer?

public class User 
{

}

//Persistence methods
static class UserDataAccess
{
   UsersDAL udal = //Choose SQL or FileSystem DAL impl.


   InsertUser(User u)
   {
      //Custom logic , is 'u' valid etc. 

      udal.Insert(u);
   }
}

abstract class UsersDAL
{    
   GetUserByID();
   InsertUser(u);
   ...
}

//implementaitons of DAL

static class UsersSQLStore : UsersDAL
{

}

static class UsersFileSystemStore : UsersDAL
{

}

Je me suis séparé de la couche de stockage à partir de la classe d'Utilisateur pour accéder à des méthodes de collecte, qui a en outre appel personnalisé DAL.

Est l'utilisation de static dans DAL mise en œuvre correcte?

Veuillez suggérer des corrections ou des façons que je peux faire mieux. Je n'ai pas beaucoup d'expérience avec l'écriture de code en couches.

Si vous ne pouvez pas prendre le temps de préciser votre question (à l'aide de Pl. au lieu de s'il vous Plaît), alors comment voulez-vous attendre de quelqu'un pour prendre le temps de répondre à votre question ou vous aider?
Je ne sais pas si ça fait mal à quelqu'un, mais juste pour sauver les gens de la lecture de trop, je l'utilise régulièrement. Au lieu de cela, je me suis concentré sur l'écriture en bas de mon exemple. Cela ne signifie pas que je ne goûtent le temps des personnes et de leurs réponses.
Pourquoi voudriez-vous faire cela au lieu d'utiliser un ORM comme LLBLGen ou Dapper? Pas besoin de réinventer la roue.

OriginalL'auteur Munish Goyal | 2011-01-06

.net architecture c#data-access-layer design-patterns

13

Aucune de ces classes doit être static. Je ne pense pas que vous devriez nom de vos classes DAL soit, en raison de sa courte pour la Couche d'Accès aux Données, et une classe en soi n'est pas un calque (dans mon esprit au moins). Vous pouvez utiliser le plus largement adopté terme référentiel à la place. Je vous suggère de faire quelque chose comme ce qui suit:
```
public class User{

}

public abstract class UserRepository{
    public abstract void InsertUser(User user);
}

public class SqlUserRepository : UserRepository{
    public override void InsertUser(User user)
    {
      //Do it
    }
}

public class FileSystemUserRepository : UserRepository{
    public override void InsertUser(User user)
    {
      //Do it
    }
}

public class UserService{
    private readonly UserRepository userRepository;

    public UserService(UserRepository userRepository){
        this.userRepository = userRepository;
    }

    public void InsertUser(User user){
        if(user == null) throw new ArgumentNullException("user");
        //other checks
        this.userRepository.InsertUser(user);
    }
}
```
Noter que le UserService est injecté avec une instance de la classe abstraite UserRepository dans son constructeur. Vous pouvez utiliser un L'Injection De Dépendance (DI) cadre pour le faire automatiquement pour vous, tels que le Château de Windsor de Château De Projet. Il vous permettra de spécifier une cartographie de l'abstraction (UserRepository) pour la mise en œuvre concrète (par exemple. SqlUserRepository) dans un fichier de configuration ou dans le code.

Espère que cela vous mène dans la bonne direction, et s'il vous plaît demander si vous avez besoin plus d'informations.

C'est le modèle le modèle. Vous êtes dans la bonne direction avec quelques modifications suggérées par Hoffmann et Jani
Grande explication. Pourquoi shoudlnt-je utiliser statique ? Si non pour les dépôts, Pour UserService je peux la rendre statique, je suppose ? 1 plus de chose (peut-être pas liées DAL): Si l'utilisateur est tenté d'insérer , puis qui doit faire cette vérification , UserService ou de l'Utilisateur de la classe elle-même par les constructeurs (depuis il ne marche pas savoir abt xistence quand il est newed)
Goyal, vous ne devez pas utiliser static car il n'est pas nécessaire pour cela. S'il est mal utilisé, static introduit inutile de le préciser dans votre demande, ce qui le rend à la fois plus difficile à déboguer et, plus important encore, il est très il est difficile de tester automatiquement. Vous voulez sans doute de lire sur le sens exact de static ici: msdn.microsoft.com/en-us/library/98f28cdx%28vs.71%29.aspx
Goyal, je pense que le UserService doit vérifier si l'utilisateur existe déjà, en demandant le dépôt si un utilisateur avec l'id/nom existe déjà. Vous avez besoin d'une méthode appelée bool UserAlreadyExists(User user) dans vos dépôts à cet effet.
Goyal, non, ce n'est pas correct. Le résumé UserRepository, l'Utilisateur de la classe, et le UserService doivent être dans la même assemblée (AssemblyA). Les différentes implémentations des dépôts peuvent être dans des assemblages de leur propre (AssemblyB/C). Le programme qui utilise le UserService aurez besoin d'une référence à la fois AssemblyA et AssemblyB (ou AssemblyC).

OriginalL'auteur Klaus Byskov Pedersen
7

Mon Humble Avis
1. Utiliser les interfaces au lieu de la classe abstraite si l'Utilisateur n'a pas de hiérarchie.
2. Écrire un générique du DAL, de sorte que vous pouvez le réutiliser comme une façade pour la couche DAL.
3. Résoudre le béton DALs par un DI-cadre
OriginalL'auteur Jahan Zinedine
6

Davy Brion a une excellente série de billets de blog sur ce sujet: situé sur GitHub

Le lien que vous avez fourni est aujourd'hui brisé. Veuillez le mettre à jour.

OriginalL'auteur tijmenvdk

Vous devez vous connecter pour publier un commentaire.