Jak poprawnie zaprojektować warstwę dostępu do danych?

Question

Mam następujące warstwy dostępu do danych (DAL). Zastanawiałem się, czy jest poprawnie skonfigurowany, czy też muszę go poprawić?

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 
{ 

} 

że oddziela warstwę pamięci z klasy użytkownikowi dostęp do metody, która ponadto zbiór wywołać jakichkolwiek niestandardowych DAL.

Czy użycie static w implementacji DAL jest poprawne?

Proszę zasugerować poprawki lub sposoby, w jakie mogę to ulepszyć. Nie mam dużego doświadczenia w pisaniu kodu w warstwach.

Answer 1

Żaden z tych klas powinny być static. Nie sądzę, że powinieneś również nazwać twoje klasy DAL, ponieważ jest skrótem od warstwy dostępu do danych, a klasa sama w sobie nie jest warstwą (przynajmniej w moim umyśle). Zamiast tego można użyć powszechnie przyjętego terminu repository. Proponuję zrobić coś jak następuje:

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

Należy pamiętać, że jest wstrzykiwany UserService z instancji klasy abstrakcyjnej UserRepository w jego konstruktora. Możesz użyć struktury Dependency Injection (DI), aby zrobić to automatycznie, na przykład Windsor Castle z Castle Project. Pozwoli to na określenie mapowania z abstrakcji (UserRepository) do konkretnej implementacji (np. SqlUserRepository) w pliku konfiguracyjnym lub w kodzie.

Nadzieję, że to wskazuje ci właściwy kierunek i zapytaj, czy potrzebujesz więcej informacji.

Answer 2

moim skromnym Opinions

1. Używaj interfejsów zamiast klasy abstrakcyjnej, jeśli użytkownik nie ma żadnej hierarchii.
2. Napisz ogólny DAL, aby ponownie użyć go jako elewacji warstwy DAL.
3. rozwiązywać konkretne dal przez ramy DI

Answer 3

Davy Brion ma doskonały zestaw wpisów na blogu na ten temat: build your own data access layer series.