[sometwo]

Czesc janusze #programowanie wlasnie sie ucze #php i tak sie zastanawiam jak robic mvc. A dokladniej chodzi o model - czy dobra praktyka bedzie tworzenie jednego modelu per tabela w bazie danych ? Powiedzmy mam tabele zamowienia i model zamowienia ktory providuje caly zestaw metod do zarzadzania zamowieniami i to tyle ? I kolejne pytanie - w kontrolerze dobra praktyka jest tylko odbieranie danych z modelu i przekazywanie danych do widoku czy dawac tam tez jakies funkcje prywatne np do parsowania daty or sth ?

[Jare_K]

@sometwo: rozbij swój model na usługi, encje, repozytoria itd. Najlepiej w ogóle zrób osobno całą domenę. Dopiero wokół tego zbuduj resztę, tj. kontrolery, widoki, DBAL itd.

[Benzen]

A dokladniej chodzi o model - czy dobra praktyka bedzie tworzenie jednego modelu per tabela w bazie danych ? Powiedzmy mam tabele zamowienia i model zamowienia ktory providuje caly zestaw metod do zarzadzania zamowieniami i to tyle ?

@sometwo: Najogólniej to tak i jest to zgodnie z mvc, ale potem rozbija się to na encje, serwisy itd.

w kontrolerze dobra praktyka jest tylko odbieranie danych z modelu i przekazywanie danych do

[MQs]

@sometwo: Uważałbym na ślepe podążanie w kierunku MVC - ta architektura średnio pasuje do http. Kontroler to jedynie dispatch requesta (co już poniekąd sam serwer potrafi jeśli się trzymać dawnych urli), widok jest w przeglądarce, a to co zwracasz to tylko odpowiednio sformatowany (serialized/markup) string danych plus nagłówki.

Kiedy zdasz sobie z tego sprawę to może okazać się, że front controller wystarczy, a obecny widok nie musi znajdować się w górnej

[sometwo]

@Jare_K: @Benzen: o co chodzi z tymi serwisami, repozytoriami, encjami, akcjami? :D Wybaczcie ale totalnie nie jestem zaznajomiony z tym :)

@MQs: szczerze mówiąc niewiele z tego zrozumiałem a momentami brzmi mało zachęcająco. Może i masz rację, nie wiem, ale dziś w niemal każdej pracy wymaga się znajomości wzorca MVC a ja muszę zarabiać na życie bo niedługo bezdomnym zostanę ;)

[Jare_K]

@sometwo: łopatologicznie: encja reprezentuje pojedynczy obiekt, np. wyssany z bazy, pliku czy API. Repo to kolekcja obiektów z operacjami do ich wyszukiwania itp. Serwis może wykonywać operacje na obiektach (usługi biznesowe) itp. Akcje to metody kontrolera, które uruchamia router na podstawie żądania HTTP. Akcje mogą operować na serwisach i powinny zwrócić odpowiedź, np. nagłówki lub widok. W webdev nie ma takiego prostego i idealnego odzwierciedlenia MVC. Ale trzeba znać jak takie

[sometwo]

@Jare_K dziekuje za odpowiedz. A wiec przykladowo - encja to obiekt ktory moze pobrac pojedynczy wpis z bazy danych lub np stworzyc nowy wpis ( settery gettery ). Repo to obiekt ktory moze przyjac wiele encji i wykonac operacje na nich np wyswietlenie zamowien z miesiaca danego. Akcje no to juz oczywiste dla mnie ale co to znaczy operowac na serwisach ? Czyli na encjach i repo ? No wiem ze mvc

[Jare_K]

@sometwo: prawie tak, z ta różnicą, ze encja sama nie pobiera nic z bazy a robi to za nią np. ORM lub np. maper czy inna abstrakcja bazy. Masz np. serwis wysyłający potwierdzenie zamówień do klienta itp. Kontroler używa tego serwisu a nie wysyła maili sam bezpośrednio ze swojej akcji. Tak, serwis może zmieniać encje, używać repo. Tak, zwykle repo to jakiegoś rodzaju tablica obiektów (encji).

[sometwo]

@Jare_K: kurde skomplikowane to ale mniej więcej coś mi się zapaliło w głowie. Dużo mi pomogłeś xD chyba najlepszym rozwiązaniem będzie przeanalizować kod kilku aplikacji MVC :> inaczej nie da rady się połapać :/

[Jare_K]

@sometwo: poczytaj tutki i książki na temat. Polecam np. Kristopher Wilson - The Clean Architecture in PHP

[Jurigag]

@sometwo: w sumie mvc to baaaardzo luźna kwestia i masa ludzi robi to zupełnie inaczej, jedni mają duże kontrolery, modele praktycznie nic nie robią, u innych i tutaj i tutaj siedzi logika, u jeszcze innych warstwa aplikacji idzie do serwisów, a reguły biznesowe w modelu a kontrolery mają klika-kilkanaście linijek itp itd