MVC. Czy ja dobrze rozumiem ten wzorzec i walidacja danych.

Na pewno nie pierwszy raz ten temat się pojawia. Natomiast, na tyle tematów i artykułów jakie przejrzałem nadal jest ich za mało lub są pisane w zbyt mało zrozumiały dla mnie sposób. A chciałbym (w końcu) nauczyć się korzystać z MVC, bo osoby z którymi rozmawiam chwalą sobie to rozwiązanie. Mam do napisanie mała aplikację, która będzie miała dwa okienka i jakiś model danych, także wydaje mi się, że to idealny moment, żeby na tak niewielkim kodzie spróbować całość zaimplementować.
Jednak problem leży po stronie zrozumienia MVC, bo trochę on do mnie nie trafia. Mam wrażenie, że kod który muszę napisać (zgodnie ze wzorcem) jest niepotrzebnie podzielony i rozwleczony (po prostu nie widzę profitów ze stosowania MVC, ale pewnie dlatego że nigdy z niego nie korzystałem).

Do rzeczy, trafiłem na taki schemat tego wzorca (http://rdn-consulting.com/blog/wp-content/uploads/2008/01/mvc-pv.gif) i ten chyba do mnie trafia, ale mimo to chciałbym tutaj go opisać własnymi słowami i prosiłbym o parę słów komentarza, czy ja na pewno dobrze rozumiem.

Model, to raczej sprawa jasna, repozytorium danych, zestaw klas do obsługi tego repozytorium, itp. Generalnie część odpowiedzialna za przechowywanie danych.
View, to w większości przypadków będzie okienko z interfejsem użytkownika.
Controller, to to magiczne coś, nad czym się zastanawiam. Ono ma niby łączyć model i widokiem przez...eventy? Tylko i wyłącznie?

Przykładowo jak ja to widzę. Użytkownik klika przycisk w widoku. Przycisk (dla użytkownika) służy do zapisu danych z trzech Textbox'ów z formatki, np. do pliku. Tyle wie użytkownik.
A to co pod spodem się dzieje, to: po kliknięciu, leci event do kontrolera. Ten odbiera go i reaguje w ten sposób, że zbiera dane z formatki (ale w samym zdarzeniu chyba też takie dane można przekazać, a może trzeba?), a następnie wywołuje jakąś metodę modelu (tutaj już nie event), która fizycznie zapisuje dane, np. do pliku. W odpowiedzi model zwraca (znowu przez event???) odpowiedź o poprawności lub błędzie do kontrolera. Ten dopiero wywołuje metodę widoku lub bezpośrednio (to drugie chyba częściej) modyfikuje formatkę jeśli należy ją zmodyfikować, albo zamyka po prostu bieżącą formatkę, albo wypisuje błąd?
I to o to w tym chodzi?
Jak tak, to jakie to ma profity w stosunku do kodu z pominiętym kontrolerem? Znika sporo eventów, widok używałby bezpośrednio metod modelu i też działa. Więc czemu jest takie parcie na MVC (lub inne jemu podobne)?

Oddzielna sprawa: w którym momencie jest walidacja danych? Można chyba spróbować robić ją po każdym TextChanged w Textbox'ach. Ale, według powyższego schematu, dane byłyby wysyłane do konrolera przez event, a ten sprawdzałby je w jakiś tam sposób (np. mógłby mieć dodatkowy obiekt jakiejś klasy, która by to sprawdzała). Następnie odsyłałby to do widoku. Czy tego typu walidacja miałaby następować bezpośrednio w widoku?
Drugi moment (odnosząc się do mojego pierwszego przykładu), to gdzieś "na trasie" między naciśnięciem przycisku, przez zapis, a powrotem z informacją o powodzeniu operacji. I w tym wypadku, walidacja powinna być przed wysłaniem danych do modelu, w sensie w kontrolerze zaraz po odebraniu eventu od widoku i jeśli dane są poprawne wywołuję dopiero metodę modelu, czy dopiero w modelu powinny być sprawdzane dane, a kontroler czekałby na ewentualne wyjątki, żeby za chwile je przekazać użytkownikowi?

Proszę o jakieś uwagi albo dobre artykuły (nie pierwsze lepsze z Google, bo te nie bardzo do mnie przemawiają...). Wiem że sporo tego napisałem, ale chciałbym wreszcie to zrozumieć, tym bardziej że niedługo czeka mnie większa aplikacja do zrobienia, więc chciałbym i ją spróbować zrobić według konwencji MVC (o ile ją zrozumiem).

Dlaczego uparłeś się na wzorzec MVC skoro piszesz aplikację desktopową. ? Są inne wzorce, które nadają się bardziej na aplikację desktopową.
W czym będziesz robił aplikację? WPF? WinForms?
Polecam zapoznać się z wzorcami MVVM (jeżeli w WPF) oraz MVP (jeżeli w WinForms).

Znaczy przede wszystkim, chciałbym zrozumieć ideę jednego, to wtedy inne (tak myślę) pójdą lepiej.
A dlaczego MVC? Bo po pierwsze ludzie z którymi rozmawiam polecają ten wzorzec, a po drugie wydaje się być bardziej uniwersalny, a za chwilę będę potrzebował napisać aplikację webową w ASP.NET, a tutaj MVC to chyba dobry wybór.

W tym konkretnym przypadku (ta mała aplikacja, którą teraz muszę napisać) będzie w WinForms, więc mogę spróbować i innego typu wzorca. Ale tak czy inaczej, zasada działania tych wzorców za pewne będzie podobna, że jest jakiś kontroler który coś robi i trzeba na to jakoś reagować. Może niepotrzebnie się uparłem na MVC, ale chciałbym od czegoś zacząć.

Dlaczego uparłeś się na wzorzec MVC skoro piszesz aplikację desktopową. ?

Czy to znaczy, że MVC nie nadaje się do desktopowych aplikacji, czy po prostu (tak jak ja to odczuwam) dodaje się w tej wersji dużo niepotrzebnego kodu, który można zastąpić w bardziej czytelny sposób?

Do pisania aplikacji desktopowych we wzorcach przeze mnie wymienionych masz gotowe frameworki, a do pisania aplikacji desktopowych w MVC sam musisz sobie stworzyć całą infrastrukturę, (przy pisaniu aplikacji webowych, masz gotowy framework - ASP.NET MVC).
Nie ma czegoś takiej jak za dużo zbędnego kodu.
Są dwie drogi:

• albo piszesz na szybko, masz szybkie efekty pracy i niską jakość kodu.
  -albo poświęcasz więcej czasu, dzielisz projekt na warstwy, z których każda z nich ma przydzieloną własną odpowiedzialność i masz wynikające z tego korzyści jak rozszerzalność, abstrakcja i testowalność.

Chciałbym pójść tą drugą drogą, przynajmniej po to, żeby wiedzieć jak to działa, żeby mieć świadomość tego co się dzieje z moim programem i co zrobić, aby polepszyć jakość.
A co do tych frameworków, to jakieś przykłady np. do wykorzystania WinForms?

I ogólnie, czy to co ja napisałem na samym początku, to tak mniej więcej działa MVC? W taki sposób aplikacja jest dzielona na części i wszystko dzieje się w eventach, czy jak? Chciałbym po prostu zrozumieć jak to działa, nie tylko jak z tego korzystać.

Od siebie mogę dodać że po przerobieniu dobrego kursu ASP.NET MVC, od razu się tobie wszystko fajnie rozjaśni. Też miałem problem ze zrozumieniem MVC, dopóki nie zobaczyłem jak to działa w ASP.NET.

Przede mną właśnie jest większy projekt w ASP.NET MVC i troszkę się obawiam jak to będzie szło. Dlatego chciałem przetestować ten wzorzec na czymś prostszym. Ale może nie ma co się spinać;)

Generalnie odnośnie MVC to pamiętaj że to NIE jest architektura całej aplikacji tylko do UI.

Model - to coś więcej niż tylko repozytoria danych. Często się o tym zapomina ale tu jest też logika biznesowa, procesy, walidacja, autoryzacja itp. NIE w Controllerze.
Oddzielny temat to własnie architektura modelu: resource-based vs service-orientated, + AOP czy też nie, itp ?

View - to wszystko co widzi użytkownik - komponenty GUI, ich layout, styl, itp.

Controller - to wszystko czego używa użytkownik - obsługa wywołanych akcji, notyfikacja widoku o zmianach, przepływ między widokami, itp.

Co do walidacji:

W modelu MUSI być cała walidacja. Pamiętaj że prędzej czy później Twój soft może dorobić się API i integracji z systemami zewnętrznymi. Wtedy nie będzie już VC bronił M przed śmieciowymi danymi wejściowymi.

W kontrolerze można walidację dublować żeby zapewnić lepszą interakcje z użytkownikiem.

Jeśli dobrze więc rozumiem, to model, to praktycznie cały backend aplikacji, do którego "na zewnątrz" udostępnia się konkretne funkcje, jakie można wykonywać na danych. A to co będzie później się działo, to zależy od implementacji. I w MVC, kontroler będzie pełnił rolę pośrednika między modelem a widokiem. Koniec. Ale...jeśli tak, to ja nadal nie mogę spać spokojnie.

W kilku, kilkunastu implementacjach, które niby były MVC, widok miał bezpośredni dostęp do danych. Nie modyfikował ich w sposób bezpośredni, ale korzystał z takich które mu zwracały jakieś wartości (chociaż gdyby chciał, to bez problemu można by było napisać kod modyfikujący model bezpośrednio). Natomiast modyfikacja danych następowała zawsze przez kontroler, który zmieniał dane (żadanie modyfikacji zawsze przez event do kontrolera), a potem kontroler wywoływał odpowiednią funkcję widoku (najczęściej będąca częścią interfejsu IView), która to odczytywała dane z modelu, żeby zaktualizować UI. Jakoś rola tego kontrolera w takim scenariuszu jest dla mnie mało potrzebna, bo to można robić tylko przez widok i też by pięknie działało.

Więc po co ten kontroler? Może mógłbym prosić o jakiś bardziej rozbudowany scenariusz, przy którym kontroler pełni kluczową i sensowną rolę? Bo to tej pory, wiele kodów które widziałem, to tylko kod który pokazywał, że ładnie rzucamy eventy, a kontroler musi być. Ale coś bardziej praktycznego?

Napisz prostą aplikację w ASP.NET MCV masz np. tutaj video tut http://pluralsight.com/training/Player?author=scott-allen&name=mvc4-building-m1-intro&mode=live&clip=0&course=mvc4-building możesz sobie to pooglądać bez pisania, na razie odpuść sobie WinForms'y i MVC na nich bo one nie wspomagają MVC. Z pewnością zrozumiesz co tutaj jest kontrolerem i do jakiej roli się sprowadza.

Okrojony przykład wysyłania przelewu w Java EE / Spring:

Widok formularza przelewu:

<form method="POST" action="/doTransfer">
  From account: <input name="fromAccount" value="${usersAccountNumber}" /><br />
  To account: <input name="toAccount" /><br />
  Amount: <input name="cashAmount" /><br />
  <input name="submit" type="submit" />
</form>

Kontroler:

// globalnie mamy oczywiście ustawione że jak user nie jest zalogowany
// to go przeniesie do formularza logowania
@Controller("/")
public class MainController {

    // to jest de facto model
    @Autowired
    private AccountService accountService;

    @RequestMapping(value="transferForm", method=RequestMethod.GET)
    public ModelAndView transferForm() {

        Account acc = accountService.getCurrentUsersAccount();

        // przekażemy tylko część modelu do widoku
        ModelAndView mv = new ModelAndView("transferForm");
        mv.addObject("usersAccountNumber", acc.getNumber());
        return mv;
    }

    @RequestMapping(value="doTransfer", method=RequestMethod.POST)
    public ModelAndView doTransfer(
        @RequestParam("fromAccount") String fromAccount,
        @RequestParam("toAccount") String toAccount,
        @RequestParam("cashAmount") Double cashAmount) {

        try {
            accountService.doTransfer(fromAccount, toAccount, cashAmount);
            // jak jest ok
            ModelAndView mv = new ModelAndView("transferOk");
            // ...
            return mv;
        } catch(Exception ex) {
            ModelAndView mv = new ModelAndView("transferFailed");
            // ...
            return mv;
        }
    }

    //...
}

Model:

// działa transakcyjnie
@Component
@Transactional
public class AccountService {

    // ma dostęp do bazy danych
    @PersistanceContext
    private EntityManager em;

    // ma dostęp do kontekstu kto woła dane żądanie i jakie ma uprawnienia
    @Autowired
    private SecurityContext sc;

    public void doTransfer(String fromAccount, String toAccount, Double cashAmount) {

        // zajmuje się typowym mięsem, sprawdza konto, czy jest kasa, czy user ma prawo je przelać, itp.
        // nie ma NIC wspólnego z GUI aplikacji

     }
}

@szopenfx dzięki za tutorial, przyda mi się, tym bardziej że niedługo będę chciał coś większego w tym zrobić. Obejrzałem dopiero pierwszych kilkanaście minut i wydaje się bardzo fajnie i przejrzyście zrobiony. jeszcze raz dzięki.
@walec51 w takim wydaniu, w aplikacji webowej to jest to bardziej jasne niż słoneczko. Właściwie to po takim fragmencie kodu, MVC jest dla mnie bardziej zrozumiałe niż kiedykolwiek:P po prostu, źle do tego podszedłem.

Będąc jeszcze w temacie wzorców, dociągnę temat do końca (i do znudzenia). Wcześniej @micc wspomniał o tym, że do WinForms lepiej stosować MVP, a do WPF wzorzec MVVM. Ponieważ ciągle przede mną mała aplikacja okienkowa (o której wspominałem na samym początku), którą chciałbym napisać zgodnie z jakimś wzorcem (żeby zobaczyć co z czym się je). To na który postawić na początek? Macie jakieś doświadczenie z nimi, żeby któryś z nich stanowczo odradzić, albo wręcz zachęcić na początek? Nie chciałbym się wpakować w jakieś bagno. Technologia czy WinForms czy WPF nie stanowi problemów, wręcz do tego co potrzebuję zrobić jest mi obojętna, bo aplikacja jest zbyt prosta.

w modelu jakieś funkcje przetwarzające? no chyba nie...
model to model....

winterfresh opisał to w 'miare' poprawnie...

Lena(R) napisał(a):

Wcześniej @micc wspomniał o tym, że do WinForms lepiej stosować MVP, a do WPF wzorzec MVVM.

Tu racja że MVC przez lata zaczął najlepiej pasować do typowego weba, a na aplikacjach desktop-owych częściej idzie się właśnie w MVP. Z MVVM osobiście nie miałem styczności, więc nie pomogę w wyborze niestety.

PS. Jak byś kiedyś przystępował do jakiegoś większego systemu co będzie miał skomplikowany model to polecam:
http://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215

Domain Driven Design obecnie króluj jako metodyka analityczna oraz wzorzec do konstruowania modelu domenowego.

Uświadomi Ci też co jeszcze siedzi w modelu poza modelem danych, wbrew temu co niektóre fajtłapy wypisują tutaj na forum.

MVC to chyba najbardziej nierozumiany wzorzec projektowy na świecie. Niektórzy śmieszni programiści (np. architekci u mnie w robocie) myślą, że użycie go automatycznie sprawia, że aplikacja jest wielowarstwowa i wspaniała. :)

Tymczasem MVC to wzorzec projektowy warstwy prezentacji (czyli aplikacji będącej GUI). Ale Modele to klasy wyświetlane w Widokach. Modele, nie Encje, jak to niektórzy (np. u mnie w robocie) robią...

Logika biznesowa, procesy, walidacja, komunikacja, ORM, cały backend jest właśnie backendem - to wszystko leży pod MVC. Mogą to być webserwisy, mogą zwykłe serwisy aplikacyjne, itd., wszystko w zależności od wielkości i poziomu skomplikowania projektu. Jedynie kontrolery odwołują się do warstw niższych, każą im wykonać jakieś operacje, odbierają wyniki, tworzą z nich Modele i przesyłają do wyświetlenia w Widokach.

somekind napisał(a):

Ale Modele to klasy wyświetlane w Widokach. Modele, nie Encje, jak to niektórzy (np. u mnie w robocie) robią...

Nie... zacytuje pierwotny dokument ze Smalltalk'a, które de facto wprowadził wzorzec MVC do annałów:

Finally, the model manages the behavior and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller)

Źródło: Applications Programming in Smalltalk-80(TM): How to use Model-View-Controller (MVC) - http://st-www.cs.illinois.edu/users/smarch/st-docs/mvc.html

(PS. To forum coś sobie z linkami nie radzi ^)

Ludzie skończcie wymyślać własne wzorce i nazywać je MVC. MVC jest dobrze udokumentowany, więc obierzcie sobie inną nazwę. Polecam DVC (data-view-controler) :P bo mylicie model domenowy o którym mowa w MVC z danymi, które czasem kontroler preparuje pod widok na bazie modelu danych (który przypominam jest tylko częścią modelu domenowego)

PS. @somekind co do reszty co piszesz to się zgadzam, jednak model w MVC to własnie ta cała reszta, której architektury/wzorców MVC już nie determinuje - ale za to określa komunikację między tymi 3 sferami

walec51 napisał(a):

PS. @somekind co do reszty co piszesz to się zgadzam, jednak model w MVC to własnie ta cała reszta, której architektury/wzorców MVC już nie determinuje - ale za to określa komunikację między tymi 3 sferami

Czy obiekty wyświetlane przez widok to nie są Modele?

somekind napisał(a):

Czy obiekty wyświetlane przez widok to nie są Modele?

Pytanie tak ogólne że nie da sie na nie odpowiedzieć. Jakie obiekty ? graficzne ? biznesowe ? skąd ?

Szczerze to nie wiem co to jest niejasnego z dokumentacji autorów tego wzorca:

Finally, the model manages the behavior and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller)

Czyli kompetencje modelu w MVC w podpunktach bo widzę że Wam się nie chce czytać albo nie znacie angielskiego:

• zarządza zachowaniem oraz danymi domeny aplikacji (bynajmniej nie internetowej) - czyli nie są to tylko dane
• dostarcza informacji - głównie dla widoku - dostarcza dane do widoku ale model TO NIE TYLKO DANE
• reaguje na instrukcje - głównie od kontrolera - dane same z siebie nie reagują

No właśnie - sporo niejasności wynika z wieloznaczności słów. Model w MVC to to, o czym piszesz, ale Modele to też obiekty wyświetlane w widokach, bo nie powinny to być bezpośrednio ani encje, ani obiekty domeny. Niektórzy mówią na takie obiekty ViewModele, ale z kolei inni twierdzą, że to nazwa prawidłowa tylko dla wzorca MVVM.

somekind napisał(a):

No właśnie - sporo niejasności wynika z wieloznaczności słów. Model w MVC to to, o czym piszesz, ale Modele to też obiekty wyświetlane w widokach, bo nie powinny to być bezpośrednio ani encje, ani obiekty domeny. Niektórzy mówią na takie obiekty ViewModele, ale z kolei inni twierdzą, że to nazwa prawidłowa tylko dla wzorca MVVM.

Wskaż mi jakieś rzetelne źródło opisujące wzorzec MVC (nie jego konkretną implementacje) gdzie jest podział/definicja na Model i Modele. MVVM powstał 15 lat po MVC. Proponuje nie mieszać i nie wymyślać własnych teorii. Można sobie dodać taką restrykcję o której mówisz do projektu ale gadanie że MVC ją wymusza jest po prostu nieprawdą.

Generalnie nie podejmuje już dalej dyskusji niepopartej źródłami.

Mam trochę dosyć dywagowania o legendach przekazywanych oralnie przez nie wiadomo kogo.

PS. Mój przykład de facto wykorzystuje klasę ModelAndView. Ale szczerze to śmiało bym dał tem bezpośrednio encje, a nawet jakąś usługę jeżeli: a) architektura tego nie zabrania, b) nie są potrzebne jakieś dodatkowe transformacje danych aby zaaplikować je do widoku, c) wiem że nie współpracuje z psychopatami co zaczną w przyszłości w widoku modyfikować encja lub wywoływać metody inne niż get/find/itp.

walec51 napisał(a):

Wskaż mi jakieś rzetelne źródło opisujące wzorzec MVC (nie jego konkretną implementacje) gdzie jest podział/definicja na Model i Modele.

Nigdzie nie napisałem, że to jest jakiś podział z MVC! :|
Zupełnie nie o to mi chodzi. Nie słyszałeś nigdy określenia "Model" ogólnie na klasę wyświetlaną przez ekran aplikacji (wszystko jedno, czy to web czy desktop)? To jak takie klasy nazywasz? Czy w ogóle nie mają specjalnej nazwy Twoim zdaniem?

PS. Mój przykład de facto wykorzystuje klasę ModelAndView. Ale szczerze to śmiało bym dał tem bezpośrednio encje, a nawet jakąś usługę jeżeli: a) architektura tego nie zabrania, b) nie są potrzebne jakieś dodatkowe transformacje danych aby zaaplikować je do widoku, c) wiem że nie współpracuje z psychopatami co zaczną w przyszłości w widoku modyfikować encja lub wywoływać metody inne niż get/find/itp.

W PoCu albo prostym tutorialu można, ale to chyba uczy złych nawyków.
W prawdziwym świecie chyba rzadko zdarza się, aby transformacje nie były potrzebne. Czasem coś trzeba spłaszczyć, czasem po prostu pewne dane lub relacje nie są w widoku potrzebne. A poza tym, encje są zazwyczaj jakoś powiązane z ORMem, np. poprzez atrybuty, którymi są udekorowane. Aplikacja webowa powinna zaś być od ORMa zupełnie niezależna.

somekind napisał(a):

Zupełnie nie o to mi chodzi. Nie słyszałeś nigdy określenia "Model" ogólnie na klasę wyświetlaną przez ekran aplikacji (wszystko jedno, czy to web czy desktop)? To jak takie klasy nazywasz? Czy w ogóle nie mają specjalnej nazwy Twoim zdaniem?

Zgodzę się że można do widoku przekazywać spreparowany podzbiór modelu domenowego. To jest ta klasa, którą de facto widzisz. Model domenowy trudno uchwycić wzrokiem bo jest wyjebisty zazwyczaj :) Natomiast sam wzorzec MVC tego nie wymaga i nie zawsze trzeba wszystko preparować. Kwestia zależna od projektu.

somekind napisał(a):

W prawdziwym świecie chyba rzadko zdarza się, aby transformacje nie były potrzebne. Czasem coś trzeba spłaszczyć, czasem po prostu pewne dane lub relacje nie są w widoku potrzebne. A poza tym, encje są zazwyczaj jakoś powiązane z ORMem, np. poprzez atrybuty, którymi są udekorowane. Aplikacja webowa powinna zaś być od ORMa zupełnie niezależna.

Na poziomie API zgodzę się. Ale żeby całe encje odcinać dla webu od ORM'a to czasem się od tego odchodzi nawet w większych projektach:

• nie wiem jak w .NET ale w Javie same klasy modelu danych dla ORM nie muszą nieć żadnych zależności na poziomie API do niego - fakt faktem pod API w runtime idzie w nich proxy ORMa
• detatching encji kosztuje,
• często wtedy zostaje wywołany przedwcześnie niepotrzebny lazy fetching

Więc de facto zeszliśmy już na temat best practice, a nie samego MVC. Dlatego też na tym poziomie jedyną poprawną odpowiedzią jest: to zależy

Pewnie chodzi o to, że klasycznie w MVC model należy rozumieć jako wszystko to, co nie jest widokiem, ani kontrolerem.
Model więc może być grubo lub cienkoziarnisty. Dobre praktyki każą nam nie operować w warstwie prezentacji bezpośrednio na obiektach biznesowych, dlatego tworzymy dodatkowe obiekty, które służą do operowania na pewnym podzbiorze obiektów domeny (viewmodele). Często kolokwialnie, na te "viewmodele" mówimy model, podczas gdy w klasycznym MVC cała warstwa aplikacji i domeny może być rozumiana jako model.

@walec51, już wiem o co Ci chodzi. Tobie chodzi o to, że np. jeśli zapisujemy dane, które mają być przypisane do użytkownika (np. autor edycji) to powinniśmy mieć osobny model, który się tym zajmie. I ja to rozumiem, ale dane do sprawdzenia nie są obracane tylko w modelu, tylko są dostarczane z kontrolera, i.e.:

# model
class Post
  # ...
  def save_as(user)
    raise "Cannot be edited by given user: #{user.id}" unless can? user, :edit
    self.editor = user
    save
  end
end

# kontroler
class PostController
  def save
    # ...
    @post.save_as(current_user)
  end
end

Więc jak widać (a przynajmniej zdaje mi się, że powinno być to widać), że model sprawdza, czy dany użytkownik może edytować ten wpis, jednak sam nie zna stanu aplikacji (zalogowanego użytkownika). Musi go otrzymać z zewnątrz, czyli kontrolera, który takowy stan jest w stanie określić, z racji iż to on odbiera dane od użytkownika.