MVVM i dostęp do bazy danych

Witam wszystkich.

Piszę projekt w WPF wykorzystując MVVM. Mój pierwszy projekt w MVVM więc ciągle się uczę i napotykam na różne "niejasności" związane z wzorcem i właśnie teraz mam dylemat - gdzie powinienem umieścić mechanizmy odpowiedzialne za komunikację z bazą danych i zapytania SQL? Nie korzystam z żadnych Entity Frameworków itp tylko korzystam z bibliotek dostarczonych przez producenta bazy (baza Pervasive, głównie wersja 12, w jednym przypadku wersja 10). Macie może jakieś materiały które w praktyczny sposób pokazywałyby jak to rozdzielić? Gdzie umieścić Data Access Layer? Googluję od kilku dni za konkretami ale większość to Entity itd. W moim projekcie stworzyłem osobny podprojekt na zasadzie "Data" i myślałem żeby tam umieszczać wszystkie zapytania i metody pobierające dane ale czy w tej warstwie powinienem się odnieść do mojego modelu i zwracać dane bezpośrednio do niego czy może z poziomu mv łączyć dane z modelem? Jakie są wasze doświadczenia? Jakie macie sprawdzone praktyki? Pewnie nie ma złotego środka ale chętnie poznam podejście innych - pozwoli to uniknąć błędów na etapie uczenia się wzorca

Cześć. Stworzyłbym DAL jako osobny projekt i tam umieścił wszystkie komponenty potrzebne do wykonywania operacji na bazie danych. Między DAL a viewmodelami utworzyłbym kolejny projekt odpowiedzialny za wykonywanie operacji biznesowych - obsługiwałby wyjątki, wykonywał zapytania na DAL, przykrywał te dane, których nie chcesz przesyłać do widoku, a następnie zwracał te dane do viewmodelu. Byłby wtedy zachowany separation of concerns, więc Twoje serwisy nie musiałyby nic wiedzieć o tym, jak wygląda widok, a widok o tym, że jakikolwiek DAL w ogóle istnieje, skoro referencja byłaby do projektu z przygotowanymi serwisami.

Na poziomie viewmodelu robiłbym z kolei mapowanie danych z serwisu już pod konkretny widok. Może się pojawić problem, gdzie z kilku różnych encji będzie korzystał np. DAL/serwisy lub widok/serwisy, więc wyodrębniłbym je wtedy do osobnego projektu z encjami. Tak mniej więcej wyglądała architektura w poprzedniej firmie, gdzie przez rok pracowałem z MVVM:). Wszystko współgrało ze wzorcem MVP, ale to jeszcze odrębny temat.

Ja to robię tak:

1. Projekt "Models" - modele biznesowe i DAO
2. Projekt "DAL" - Cała abstrakcja do obsługi bazy danych. U Ciebie może to być już konkretna implementacja
3. Projekt z konkretną obsługą bazy danych, np: "DAL.NHibernate", "DAL.MSSQL" itd.
4. Projekt "Services" - serwisy, które wiedzą o DAL i o Modelach. Np:

public class ClientService: IClientService
{
  IDbAccess db;

  public ClientService(IDbAccess db)
  {
    this.db = db;
  }

  public void AddClient(Client c)
  {
    db.SaveOrUpdate(c);
  }
}

5. Projekt klienta. Zawiera widoki, ViewModele i konktrolery. Wie o Modelach i o serwisach, np:

public class ClientController: BaseController
{
    IClientService service;

    public ClientController(IClientService service): base()
    {
        this.service = service;
    }

    public bool AddClient(Client c)
    {
        //tutaj trochę magii, ale wszystko sprowadza się do:
       try
       { 
           service.AddClient(c);
           return true;
       }catch(Exception ex)
      {
         return false; //w rzeczywistości powinna być tu jakaś obsługa wyjątków
      }
    }
}

public class ClientViewModel: BaseViewModel
{
    ClientController contr;

    public ClientViewModel(ClientController contr)
    {
        this.contr = contr;
    }
}

W większości moich projektów mam jeszcze kilka innych warstw, ale pełnią one dość specyficzne role(np. komunikacja po API), więc tutaj ich nie pokazuję, żeby nie zaciemniać.
Oczywiście jak widzisz, większość ma swoje interfejsy. Interfejsy mogą być wyrzucone do innego projektu np. "Infrastructure" lub w zależności od tego, co piszesz, mogą być w innych projektach - np. wydzielone w "Services", ale to może powodować problemy przy testowaniu.