Как правильно спроектировать слой доступа к данным?

Question

У меня есть следующий уровень доступа к данным (DAL).Мне было интересно, правильно ли он настроен или мне нужно его улучшить?

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
{

}

Я отделил слой хранения от класса User для доступа к коллекции методов, которая в дальнейшем вызывает любой пользовательский DAL.

Правильно ли использовать static в реализации DAL?

Пожалуйста, предложите исправления или способы, которыми я могу сделать это лучше.У меня нет большого опыта написания кода в слоях.

Answer 1

Ни один из этих классов не должен быть static.Я не думаю, что вы должны также называть ваши классы DAL, потому что это сокращение от уровня доступа к данным, а класс сам по себе не является слоем (по крайней мере, на мой взгляд).Вместо этого вы можете использовать широко принятый термин хранилище .Я предлагаю вам сделать что-то вроде следующего:

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);
    }
}

Обратите внимание, что UserService внедряется с экземпляром абстрактного класса UserRepository в его конструкторе.Вы можете использовать инфраструктуру Dependency Injection (DI), чтобы сделать это автоматически, например, Виндзорский замок из Castle Project .Это позволит вам указать отображение от абстракции (UserRepository) до конкретной реализации (например, SqlUserRepository) в файле конфигурации или в коде.

Надеюсь, что это указывает вам верное направление, ипожалуйста, спросите, если вам нужна дополнительная информация.

Answer 2

Мои скромные мнения

1. Используйте интерфейсы вместо абстрактного класса, если у пользователя нет иерархии.
2. Напишите общий DAL, чтобы вы могли использовать его в качестве фасада для DALслой.
3. Разрешить бетонные DALs с помощью структуры DI

Answer 3

У Дэви Брайона есть отличный набор постов на эту тему: , расположенный на GitHub