Witajcie,
jak co niektórzy wiedzą uczę się Entity Framework i chcę go dobrze zastosować wespół z MVVM.
Teraz chcę się zapytać czy moje podejście jest dobre?
Wołam @DibbyDum i innych mvvm'owców.
PS: Wiem, że EF jest jaki jest ale mimo wszystko chcę go poznać. Później równolegle sobie może nHibernate zrobię.
Odnośnie ViewModelu:
Słowem wstępu MVVM to wzorzec architektury dzielący ogólnikowo aplikacje na trzy warstwy odseparowane od siebie.
C# View odpowiada za GUI, czyli za wygląd formatek za wszelakie wodotryski czy to napisane w XAML czy w c# code-behind bez różnicy.ViewModel tutaj leci logika aplikacji, głownie odpowiedzialna za pobierz dane z Model przekaż do View i z powrotem.Model tutaj powinna być logika biznesowa (domena), serwisy, repozytoria i inne szmery bajer które korzystają na przykład z bazy danych za pośrednictwem EF.A więc wracając do twojego kodu:
ViewModel ten "DbContext" i ubrać to w jakieś serwisy po stronie modelu.Model to nie mapowanie tabelki z bazy danych.View, ViewModel i Model to ogólniki pod nimi zawsze kryją się bardziej szczegółowe wzorce i implementacje.
P.S. nie przepracowałem ani pół sekundy jako WPF/MVVM developer więc równie dobrze mogę pieprzyć głupoty. :)
Dzięki wszystkim za feedback. No ja juz próbuję mvvm używać dobre dwa latka :) Ciągle dowiaduję się czegoś nowego :)
@DibbyDum, @teo215 Czy chodziło o taki serwis?
using System;
using System.Collections.Generic;
using System.Collections.ObjectModel;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using Library.Model;
namespace Library.Services {
public interface ILibraryService {
ICollection<Book> GetBooks();
ICollection<Author> GetAuthors();
ICollection<BooksView> GetBooksView();
bool InsertBook(Book book);
bool InsertAuthor(Author author);
bool Associate(int bookId, int authorId);
}
public class LibraryService : ILibraryService {
public ICollection<Book> GetBooks() {
using (var db = new LibraryContext()) {
return db.Books.ToList();
}
}
public ICollection<Author> GetAuthors() {
using (var db = new LibraryContext()) {
return db.Authors.ToList();
}
}
public ICollection<BooksView> GetBooksView() {
using (var db = new LibraryContext()) {
return db.BooksView.ToList();
}
}
public bool InsertBook(Book book) {
try {
using (var db = new LibraryContext()) {
db.Books.Add(book);
return db.SaveChanges() > 0;
}
}
catch (Exception) {
return false;
}
}
public bool InsertAuthor(Author author) {
try {
using (var db = new LibraryContext()) {
db.Authors.Add(author);
return db.SaveChanges() > 0;
}
}
catch (Exception) {
return false;
}
}
public bool Associate(int bookId, int authorId) {
try {
using (var db = new LibraryContext()) {
var book = db.Books.Single(b => b.Id == bookId);
var author = db.Authors.Single(a => a.Id == authorId);
book.Authors.Add(author);
author.Books.Add(book);
return db.SaveChanges() > 0;
}
}
catch (Exception ex) {
System.Windows.MessageBox.Show(ex.ToString());
return false;
}
}
}
}
Generalnie baza jest prosta. Taka tam... żeby ogarnąć działanie ORM:
Klasy Book i Author to fizyczne tabele w bazie danych. Klasa BookView to klasa, która bierze dane z widoku zrobionego w bazie.
Czy chodziło o takie (albo podobne) podejście? :)
PS: Nie zwracajcie uwagi na ogolny Exception i to, że jest tam tylko return false. Chodzi generalnie o ideę serwisu. W viewmodelu będzie luźna referencja w postaci interfejsu.
Czyli tak jak się w sumie domyślałem. :) I te serwisy plus to co jest z ORM'a to właśnie nasz model. :)
Również podpisuję się pod słowami @DibbyDum
Serwis powinien zwracać IList.Serwis powinien zawierać logikę biznesową a nie operować na pojedynczych tabelach (Wtedy był by tylko nakładą na EF).
Zazwyczaj tworzę kilka mniejszych serwisów gdzie każdy z nich jest odpowiedzialny za konkretną cześć logiki biznesowej.
teo215 napisał(a):
- Skoro już masz luźne wiązanie śmiało możesz wstrzyknąć tą zależność za pomocą konstruktora abyś nie tworzył instancji w ramach ViewModelu.
Rozwiń jak możesz. Teraz mam właśnie instancję, nazwijmy to IService w VM.
fasadin