Bardzo ciekawe, ale niestety coś takiego mi się nigdy nie udało.
A mi się dziwne (nawet bardzo) wydało to co napisałeś.
Zawsze uważałem Cię za co najmniej doświadczonego programistę, a tu wychodzi na to że nie wiesz co to jest MVC.
No chyba, że masz zupełnie co innego na myśli.
Jeśli tak, to co to takiego?
Nic nie szkodzi. O ile wspomniałem, że jest to wg mnie najciekawszy sposób na tworzenie aplikacji okienkowych
Dlaczego najciekawszy?
, to należy zaznaczyć, że sposób ten nie jest przeznaczony dla każdego projektu.
Dlaczego nie dla każdego?
Podejście, jakie wtłacza nam Delphi do głów od 25 lat (czyli RAD) nadaje się co najwyżej do bardzo prostych aplikacji albo prototypów.
Tak, wiem co napisałem.
Tak, zdaję sobie sprawę, że sposobem RAD (czyli dzierga się formatki w edytorze i oprogramowuje onClicki) powstało wiele bardzo dużych aplikacji.
I tak wiem, jakie problemy za tym idą.
Poza tym nie jest ”natywny” dla Free Pascala czy Delphi, bo całe LCL/VCL opiera się właśnie o zdarzenia
Jak wszystko inne podobne rozwiązania, opierają się na zdarzeniach.
Nie zawsze to nazywa się tak samo i działa identycznie, ale co do zasady to wszystko obsługuje zdarzenia.
znajdujące się w modułach formularzy.
Tak robi IDE, kiedy się dwukliknie na zdarzeniu.
Co nie znaczy że to jakiś wymóg, a raczej przyjęta konwencja działania IDE.
Dlatego całkowite odcięcie logiki od formularzy (jak pisałem w poprzednim poście), bez wyraźnej potrzeby i konkretnego pomysłu, jest bezcelowe.
No nie.
Bezcelowe są tak autorytarne stwierdzenia ;)
A pomysł (a raczej strategia albo lepiej - architektura) potrzebny jest zawsze.
Tak czy siak, tego typu podejście jest zasadne raczej zawsze, zwłaszcza kiedy dany projekt będzie się rozwijał i należy go utrzymywać.
Im większe potrzeby w zakresie elastyczności (np. różne widoki tych samych danych dla różnych klientów naszej aplikacji), tym korzyść z separacji poszczególnych odpowiedzialności (jak we wzorcach MVC czy MVVM) kodu programu jest większa.
W sumie to nawet nie miałbym sensownego pomysłu na taki mechanizm.
Zamiast generować zdarzenia w module formularza,
Generować?
Masz na myśli to, że szablon metody obsługi zdarzenia generowany jest przez IDE po dwukliku na zdarzeniu?
tworzy się je w zewnętrznej klasie. W tych zdarzeniach wykonuje się jakąś tam logikę. Podczas tworzenia instancji formularza, przypisuje się je do odpowiednich zdarzeń odpowiednich komponentów. Wychodzi na to samo co w przypadku standardowych eventów, ale różnica polega na tym, że można wykorzystać dowolny formularz do triggerowania danych działań.
Generalnie, zgoda.
Co prawda uprościłeś to okrutnie, ale OK.
Jest tylko jeden tyci problemik w VCL/LCL (i w FMX również).
Otóż, tam metoda obsługi \darzenia może być tylko jedna. I kropka.
Co przy takich rozwiązaniach jest pierwszym problemem, który należy rozwiązać.
Zgodnie z wzorcem MVC kod obsługujący zdarzenia to Controller.
I prędzej czy później zajdzie potrzeba posiadania wielu kontrolerów dla tej samej instancji formularza, a to oznacza, że dla jednego OnClicka może być więcej niż jedna metoda, która na niego reaguje.
Można to rozwiązać dwojako; albo zapewnimy sobie mechanizm tzw. multicast events, który pozwoli na obsługę wielu metod obsługi tego samego zdarzenia, albo pójdziemy w kierunku rozwiązań, które teraz są najlepiej znane jako Flux/Redux.
Wg mnie bardzo dobrym rozwiązaniem tego problemu wydaje się wykorzystanie idei message bus, a dla Delphi mamy nawet coś niezłego, czyli DEB.
Zwykle zdarzenia formularza, oprócz wykonywania logiki, zmieniają też stan innych komponentów znajdujących się na formularzu. Np. zmiana zaznaczenia radiobuttona powoduje zablokowanie/odlokowanie innego komponentu lub ich całej grupy. Aby mieć możliwość wykonania takich działań poza modułem formularza, referencje tych komponentów muszą być również gdzieś przechowywane.
Wybacz, ale to jest masło maślane.
Jak chcesz mieć obiekt Button klasy TButton bez utworzonego obiektu klasy TButton?
Te referencje są **ZAWSZE ** dostępne.
W przypadku wyklikanego w IDE formularza, są zagregowane i dostępne publicznie w obiekcie klasy danego formularza.
Ogólnie temat rzeka, raczej nie na ten wątek.
Prawda ;)
Sam nigdy nie wykorzystałem w pełni takiego podejścia, ale wielokrotnie zastanawiałem się nad tym jak takie coś wykonać i kiedy byłoby to przydatne.
A że w praktyce mi się coś takiego nigdy nie przydało, to cóż… ;)
Od ponad 10 lat rozwijam aplikacje w ten sposób.
I faktycznie, temat jest ogromny.
Ale jakby ktoś coś chciał pokombinować i ma zacięcie, to proszę jest gotowiec znany jako MVVM Starter Kit.
Są pewne różnice pomiędzy MVC a MVVM, ale oba opierają się na tej samej idei.
Poza tym, MVVM wydaje się bardziej dopasowane do idei RAD.