Czy przekazanie VM do repozytorium jest zgodne ze wzorcem?

Odpowiedz Nowy wątek
2018-08-03 21:28
0

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

Pozostało 580 znaków

2018-08-03 23:28
0

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.

edytowany 1x, ostatnio: jacek.placek, 2018-08-03 23:29
Czytałem w jakimś artykule, że IQueryable powoduje wyciekanie abstrakcji. Z drugiej strony IQueryable zapożyczyłem z przykładów z książki https://helion.pl/ksiazki/asp[...]m-freeman,aspnm7.htm#format/d, "ponieważ pozwala na efektywne wykonywanie zapytań do kolekcji obiektów." - bakunet 2018-08-03 23:36
@jacek.placek: Kontroler dostaje IEnumerable, które wypełniamy IQueryable ze względu na SELECT TOP(X)? czy o co chodzi? - WeiXiao 2018-08-03 23:38
No tak, bo co metoda kontrolera jest w stanie zrobić z IQueryable? Cały DAL musiałby być w kontrolerze z aktywnym połączeniem do bazy no i mamy encje na twarzy. - jacek.placek 2018-08-04 10:32

Pozostało 580 znaków

2018-08-03 23:31
0

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


"HUMAN BEINGS MAKE LIFE SO INTERESTING. DO YOU KNOW, THAT IN A UNIVERSE SO FULL OF WONDERS, THEY HAVE MANAGED TO INVENT BOREDOM."
edytowany 1x, ostatnio: somekind, 2018-08-04 13:03
Pokaż pozostałe 6 komentarzy
Masło maślane? Nie rozumiem. Repozytorium to taka kolekcja obiektów, więc przekazuje się jej obiekty i pobiera też obiekty, żadnych ID ani viewmodeli. - somekind 2018-08-04 13:00
szukałem w guglu "aggregate robot c#" i nic nie znajduje. hmmm... - Wibowit 2018-08-04 13:03
Już poprawione, owszem autokorekta z telefonu z ułomnym systemem podłej korporacji zepsuła. - somekind 2018-08-04 13:04
Manipulują wynikami :/ - jacek.placek 2018-08-04 13:05
Teoretycznie, jeśli nie musisz trzymać Agregatu w pamięci to nie potrzebujesz Repozytium. - ._. 2018-08-05 22:09

Pozostało 580 znaków

2018-08-04 01:19
._.
0

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. - bakunet 2018-08-04 06:53

Pozostało 580 znaków

2018-08-04 07:35
._.
0

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.

edytowany 1x, ostatnio: ._., 2018-08-04 07:39

Pozostało 580 znaków

2018-08-04 08:23
0
._. 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?

Pozostało 580 znaków

2018-08-04 09:07
._.
0

MS pomija kwestię repo

A to co ;#

https://docs.microsoft.com/pl[...]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

Ok, na tej stronie jeszcze mnie nie było :) I chętnie poczytam o DDD i SOA. Dzięki! - bakunet 2018-08-04 10:57
No ale ten link też średni jest. Pokazuje dokładnie to, że tworzenie "repo" jest niepotrzebne. Wszystko co tam jest w tym "repo" jest w DbContext. A nawet więcej i lepiej :) - jacek.placek 2018-08-04 13:16
@._.: Którą książkę o SOA polecasz? - Kokoniłaj 2018-08-04 17:19

Pozostało 580 znaków

2018-08-04 10:16
1

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

}
edytowany 1x, ostatnio: jacek.placek, 2018-08-04 10:25
Klasa Service wygląda ciekawie. Bądź co bądź chcę poczytać o wzorcach projektowych, żeby nie poruszać się dalej po omacku - bakunet 2018-08-04 17:01

Pozostało 580 znaków

2018-11-25 14:28
0
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.c[...]-with-the-repository-pattern/

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

edytowany 1x, ostatnio: bakunet, 2018-11-25 14:30

Pozostało 580 znaków

2018-11-25 17:06
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.c[...]-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.


"HUMAN BEINGS MAKE LIFE SO INTERESTING. DO YOU KNOW, THAT IN A UNIVERSE SO FULL OF WONDERS, THEY HAVE MANAGED TO INVENT BOREDOM."

Pozostało 580 znaków

2018-11-27 14:46
0

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.c[...]-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.

edytowany 2x, ostatnio: bakunet, 2018-11-27 14:48

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0