Czy przekazanie VM do repozytorium jest zgodne ze wzorcem?

Hej, tak się zastanawiam, czy przekazanie VM ro repozytorium w MVC jest zgodne ze wzorcem, jeśli modelem widoku jest ViewModel? Przykład:
IRepo:

public interface IProjectRepository
    {
        IQueryable<Project> Projects { get; }

        void SaveProject(Project project, ProjectViewModel projectVM); //przekazujemy VM

        Project DeleteProject(int projectID);
    }

EFRepo:

public void SaveProject(Project project, ProjectViewModel projectVM) //przekazany VM
        {
            project.Name = projectVM.Name;
            project.PictureUrl = projectVM.PictureUrl;
            project.BackColor = projectVM.BackColor;
            project.Comments = projectVM.Comments;
            project.WebUrl = projectVM.WebLink;
            project.GitHubUrl = projectVM.GitHubLink;
            project.WorkLogUrl = projectVM.WorkLogUrl;
            project.YouTubeUrl = projectVM.YouTubeUrl;
            project.CompletionDate = projectVM.CompletionDate;
            if (project.ProjectID == 0)
            {
                _context.Projects.Add(project);
            }
        }

Może być jak nie masz nic innego ale po co przekazujesz jeszcze Project i skąd to bierzesz?
No i nie zwracaj IQueryable do kontrolera.

Nie, repozytorium operuje na agregate rootach, a nie na view modelach.

Z drugiej strony IQueryable zapożyczyłem z przykładów z książk

Przecież "Adam Freeman" to bajko pisarz.

Spoko się czyta. Jedynie zakończenie jest do przewidzenia. Zawsze wszyscy giną ;) Na Amazonie był chyba najlepiej oceniany.

To jest gościu, który przepisuje tutki z dokumentacji MS i nazywa to zaawansowanym programowaniem. A potem taki Kowalski po przeczytaniu tej książki zaczyna od testowania kontrolera, w którym znajdują się repozytoria a persistence od EF nazywany jest Core Domain. ;| Tutki od MS są w opłakanym stanie one prezentują jedynie jakąś mechanikę frameworka, lecz nie mają nic wspólnego z racjonalnym wykorzystaniem wzorców czy architektury, co nie jest tam wyszczególnione.

._. napisał(a):

Spoko się czyta. Jedynie zakończenie jest do przewidzenia. Zawsze wszyscy giną ;) Na Amazonie był chyba najlepiej oceniany.

To jest gościu, który przepisuje tutki z dokumentacji MS i nazywa to zaawansowanym programowaniem. A potem taki Kowalski po przeczytaniu tej książki zaczyna od testowania kontrolera, w którym znajdują się repozytoria a persistence od EF nazywany jest Core Domain. ;| Tutki od MS są w opłakanym stanie one prezentują jedynie jakąś mechanikę frameworka, lecz nie mają nic wspólnego z racjonalnym wykorzystaniem wzorców czy architektury, co nie jest tam wyszczególnione.

Nie zgodzę się, bo przerobiłem tutki MS i jego książkę i różnice w architekturze są znaczące. Dla przykładu MS pomija kwestię repo, choć wspominają o tym, że wielu koderów korzysta zeń, ale się skupiają jedynie na mechanice EF i Net Core.

A skąd Freeman czerpie wiedzę, nie wiem. Polecisz mi coś lepszego?

MS pomija kwestię repo

A to co ;#

https://docs.microsoft.com/pl-pl/aspnet/mvc/overview/older-versions/getting-started-with-ef-5-using-mvc-4/implementing-the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application

Jeśli cię interesuje sama mechanika Frameworka, to ok.

Jak cię interesuje architektura, wzorce, to polecam książki o DDD, SOA, itp

@bakunet: "repo" kontrolerze to jeszcze nie architektura. To tylko przykład udający architekturę, że niby masz jakieś warstwy czy coś.
Bierz poprawkę na to, że Repository to wzorzec z DDD jak napisał @somekind, operujący na agregate robotach (sic!).

To co ty masz i co jest w wielu tutorialach, książkach i kursach mających też "zaawansowane" w nazwie to raczej warstwa dostępu do danych (DAL) i nie powinna być ona obecna kontrolerach (jeśli nie wiesz co robisz). Czasem w CRUDach osobiście dopuszczam ale raczej w jakichś narzędziach okołoaplikacyjnych. Jakieś konfiguratory, importerty itp.

W prostym przypadku lepiej zrobić prosty serwis gadający przez "repo" (jeśli już musisz mieć takie "repo") z bazą danych a kontroler używa metod serwisu.

class ProjectService{
    public IEnumerable<ProjectViewModel> GetList()
    {
        ...
    }

    public void SaveProject(ProjectViewModel pvm)
    {
        using(var rep = new ProjectRepository())
       {
            var project = new Project();
            // przypisanie danych albo jakeiś mapowanie
            p.Name = pvm.Name;  
            rep.Save(p);
        }
    }

}

I jak widać, po namyśli (sic!), okazuje się, że można nie tworzyć żadnego "repo" tylko użyć od razu DbContextu z EF w metodach serwisu.

class ProjectService{
    public IEnumerable<ProjectViewModel> GetList()
    {
        ...
    }

    public void SaveProject(ProjectViewModel pvm)
    {
        using(var db = new ProjectDbContext())
       {
            var project = new Project();
            // przypisanie danych albo jakieś mapowanie
            p.Name = pvm.Name;  
            db.Projects.Add(p);
            db.SaveChanges();
        }
    }

}

somekind napisał(a):

Nie, repozytorium operuje na agregate rootach, a nie na view modelach.

Hej, odgrzewam stary kotlet, bo nie wiem czy dobrze zrozumiałem.

Mam IRepository dla modelu, w którym eager loading dla wszystkich zapisów wygląda następująco:
IEnumerable<Project> GetAllProjects { get; }

to czy wczytanie dla jednego wpisu powinno wyglądać tak?
Project GetOneProject(int? projectID);

czy tak?
Project GetOneProject { get; }

I kolejna kwestia, spotkałem się ze zdaniem w tym artykule:
https://programmingwithmosh.com/entity-framework/common-mistakes-with-the-repository-pattern/

ze w repozytorium nie powinno być usuwania/update. W takim razie powinny się one odbywać w kontrolerze?

bakunet napisał(a):

Mam IRepository dla modelu, w którym eager loading dla wszystkich zapisów wygląda następująco:
IEnumerable<Project> GetAllProjects { get; }

Nie rozumiem jaki to ma związek z eager loading. Nie wiem też czemu właściwość ma w nazwie "Get", bo nazwy właściwości powinny być rzeczownikami i nie zawierać czasowników. Czasowników używa się do określania operacji, czyli metod.
Nie wiem też, po co taka operacja jak "GetAll", bo pobieranie wszystkich rekordów praktycznie nigdy nie ma sensu, praktycznie zawsze zachodzi potrzeba jakiegoś filtrowania.

to czy wczytanie dla jednego wpisu powinno wyglądać tak?
Project GetOneProject(int? projectID);

czy tak?
Project GetOneProject { get; }

Powinno być metodą. Nie bardzo tylko rozumiem w jakiej sytuacji ID mogłoby mieć wartość null.

I kolejna kwestia, spotkałem się ze zdaniem w tym artykule:
https://programmingwithmosh.com/entity-framework/common-mistakes-with-the-repository-pattern/

ze w repozytorium nie powinno być usuwania/update. W takim razie powinny się one odbywać w kontrolerze?

Nie. Nie powinno ich być w ogóle, bo jak niby miałaby wyglądać jej implementacja? Update to przecież zmiana właściwości obiektu, wystarczy później zatwierdzić unit of work, aby ta zmieniona wartość została utrwalona.

Słuszne uwagi w poprzednim wpisie.

somekind napisał(a):

bakunet napisał(a):

I kolejna kwestia, spotkałem się ze zdaniem w tym artykule:
https://programmingwithmosh.com/entity-framework/common-mistakes-with-the-repository-pattern/

ze w repozytorium nie powinno być usuwania/update. W takim razie powinny się one odbywać w kontrolerze?

Nie. Nie powinno ich być w ogóle, bo jak niby miałaby wyglądać jej implementacja? Update to przecież zmiana właściwości obiektu, wystarczy później zatwierdzić unit of work, aby ta zmieniona wartość została utrwalona.

A nawiązując do tej odpowiedzi, to Adam Freeman podaje sporo przykładów, w których wrzuca w repozytoria metody dodawania, usuwania, update obiektów. Przykład interfejsu repo z jego książki:

public interface IRepository
{
IEnumerable<Reservation> Reservations { get; }
Reservation this[int id] { get; }
Reservation AddReservation(Reservation reservation);
Reservation UpdateReservation(Reservation reservation);
void DeleteReservation(int id);
}

(s. 619 ASP.NET CORE MVC 2. ZAAWANSOWANE PROGRAMOWANIE)

Bądź co bądź na mojej liście do dalszego ogarniania jest właśnie architektura aplikacji, żeby już więcej nie brać złych przykładów.

Gość nie jest programistą tylko zawodowym autorem książek. Jego książka jest bardzo dobra jeśli chodzi o pokazanie frameworka MVC, ale nie zawiera ani jednego dobrego architektonicznie kawałka kodu. No i przede wszystkim, to co on nazywa repozytorium nie jest wcale repozytorium, lecz zwykłym DAO.