Temat: Wzorzec MVC i orientacja na model dziedziny

Nie tylko Fowler pisze, że po nabraniu wprawy ma sens w niemalże każdym większym projekcie korzystać z wzorców Domain Model i MVC.

Niestety znają ten model (dane z konferencji) nieliczne grupy programistów. Dlaczego tak jest? Dlaczego te wzorce są tam mało popularne w praktyce? Nie sa znane czy sa jednak złe?

Temat: Wzorzec MVC i orientacja na model dziedziny

Od razu ciśnie się na usta pytanie: jacy programiści? Programista to dość rozciągliwe i niezbyt konkretne pojęcie.

Co do tego czy wzorce są dobre, czy złe to zależy od ich zastosowania. Każdy wzorzec powstał w wyniku rozwiązania określonego problemu. Kiedy takich podobnych i niezależnie powstałych rozwiązań jest więcej mówimy o wzorcu. Zostaje on udokumentowany i przedstawiony w literaturze. Pamiętać jednak należy że każdy wzorzec posada motywację stosowania, ale także wady i obciążenia jakie ze sobą niesie. To projektant decyduje o skorzystaniu z konkretnego wzorca ze wszystkimi tego konsekwencjami.

Właśnie, projektant - nie programista. Wszak mówimy tu o wzorcach projektowych, nie programistycznych (implementacyjnych). Pytanie, czy programista musi znać te wzorce? O ile znajomość MVC jest pożądana, to znajomość np. DDD (Domain Driven Design) nie jest mu już potrzebna. Programista dostaje formalną specyfikację, np. w postaci UML, i musi ją zaimplementować. Już F.P. Brooks Jr. wskazywał, że implementator nie musi znać projektu systemu, ale musi mieć dobrą dokumentację.

Temat: Wzorzec MVC i orientacja na model dziedziny

Adam Brodziak:
Od razu ciśnie się na usta pytanie: jacy programiści? Programista to dość rozciągliwe i niezbyt konkretne pojęcie.

No fakt... c.d.n.

Co do tego czy wzorce są dobre, czy złe to zależy od ich zastosowania. Każdy wzorzec powstał w wyniku rozwiązania określonego problemu. Kiedy takich podobnych i niezależnie powstałych rozwiązań jest więcej mówimy o wzorcu. Zostaje on udokumentowany i przedstawiony w literaturze. Pamiętać jednak należy że każdy wzorzec posada motywację stosowania, ale także wady i obciążenia jakie ze sobą niesie. To projektant decyduje o skorzystaniu z konkretnego wzorca ze wszystkimi tego konsekwencjami.

Miałem na myśli systemy biznesowe... uściślam :)

Właśnie, projektant - nie programista. Wszak mówimy tu o wzorcach projektowych, nie programistycznych (implementacyjnych). Pytanie, czy programista musi znać te wzorce? O ile znajomość MVC jest pożądana, to znajomość np. DDD (Domain Driven Design) nie jest mu już potrzebna. Programista dostaje formalną specyfikację, np. w postaci UML, i musi ją zaimplementować. Już F.P. Brooks Jr. wskazywał, że implementator nie musi znać projektu systemu, ale musi mieć dobrą dokumentację.

I o to dla mnie chodziło. :) nie raz widuje ogłoszenia o prace: "szukamy analityka programistę" i co tu ma sens w takim pytaniu? Ale mam odpowiedź na swoje pytanie: programista implementuje projekt. Programiści powinni znać UML (no bo tę dokumentacje jakoś trza stworzyć i chyba nie prozą). Jednak Analityk i projektant także musi znać UML i analizę obiektową (zakładając, że mowa o obiektowych technikach).

Zawężam więc pytanie do systemów biznesowych.:) i usuwam programistów wstawiając w to miejsce analitykow i projektantów. :)

Temat: Wzorzec MVC i orientacja na model dziedziny

A ja bym zaczął od tego, że nie zawsze i nie wszędzie, gdzie powstają systemy biznesowe, są one w ogóle projektowane. Nawet jeśli już ktoś próbuje je zaprojektować, to czasem tym kimś jest po prostu kierownik zespołu programistów. Często zdarza się także, że programiści mają tak duży zakres odpowiedzialności, że to w ich obowiązku jest dbanie o wzorce projektowe.

Myślę, że jest już ktoś mieni się projektantem, to albo buduje swoją aplikację biznesową w oparciu o dobry model domeny, albo ma swoje mocne argumenty przeciwko takiemu postępowaniu (ja takich argumentów akurat nie znam, ergo korzystam z DDD).

Jeśli ktoś ma takie argumenty (w sensie alternatywne podejście) - chętnie się czegoś dowiem nowego:)

Temat: Wzorzec MVC i orientacja na model dziedziny

Jarek Żeliński:
Nie tylko Fowler pisze, że po nabraniu wprawy ma sens w niemalże każdym większym projekcie korzystać z wzorców Domain Model i MVC.

Niestety znają ten model (dane z konferencji) nieliczne grupy programistów. Dlaczego tak jest? Dlaczego te wzorce są tam mało popularne w praktyce? Nie sa znane czy sa jednak złe?

Jak się wydaje, większość programistów to użytkownicy Visual Studio (większość programów pisze się pod Windows oraz znakomita większość programów pod Windows jest pisana w VS). Spójrzmy na strukturę domyślnego projektu Windows Forms: implementowane są dwa kawałki MVC: Controller (odpowiedzi na eventy) i View (interfejs graficzny). Jednak nie jest prosto pod VS dodać ostatnią część tej układanki (Model, czyli np. źródło danych). Po prostu trzeba za dużo rzeczy zmieniać w takim domyślnym projekcie. Już szybciej jest utworzyć pusty projekt i wstawić ręcznie MVC. Jednakże wtedy rezygnujemy z graficznych kreatorów (te przesuwanie widgetów myszą, PPM na nich w celu ich edycji i LPM w celu dodania eventu). MVC jest zatem "nieopłacalny".

Temat: Wzorzec MVC i orientacja na model dziedziny

Tomasz Krzal:
nich w celu ich edycji i LPM w celu dodania eventu). MVC jest zatem "nieopłacalny".

A jak z opłacalnością w sensie kosztów konserwacji? program bez takiego (lub podobnego) wzorca jest bardzo trudno w konserwacji i rozbudowie.....

Temat: Wzorzec MVC i orientacja na model dziedziny

Jarek Żeliński:

A jak z opłacalnością w sensie kosztów konserwacji? program bez takiego (lub podobnego) wzorca jest bardzo trudno w konserwacji i rozbudowie.....

Konserwacja i rozbudowa takiego programu rośnie wykładniczo z czasem. Użyłem słówka 'nieopłacalny' w cudzysłowiu mając na myśli wygodę programisty. Można pisać w VS ogólnie na dwa sposoby: łatwy start i trudny koniec albo trudny start (MVC) i łatwy koniec. Co wybierze programista, który chce jak najszybciej odwalić robotę? :)

Temat: Wzorzec MVC i orientacja na model dziedziny

Tomasz Krzal:

Jarek Żeliński:

A jak z opłacalnością w sensie kosztów konserwacji? program bez takiego (lub podobnego) wzorca jest bardzo trudno w konserwacji i rozbudowie.....

Konserwacja i rozbudowa takiego programu rośnie wykładniczo z czasem. Użyłem słówka 'nieopłacalny' w cudzysłowiu mając na myśli wygodę programisty. Można pisać w VS ogólnie na dwa sposoby: łatwy start i trudny koniec albo trudny start (MVC) i łatwy koniec. Co wybierze programista, który chce jak najszybciej odwalić robotę? :)

:)

Temat: Wzorzec MVC i orientacja na model dziedziny

Jakby się tak trochę nad tym zastanowić to kwestia z konferencji (czemu znajomość MVC jest tak słaba) ma następujące odpowiedzi:

1) Niewiele środowisk programistycznych ma wbudowane domyślne szablony projektów z MVC. Jeśli tak by było, to potem prawie 100% programistów (nawet domorosłych) pisałoby czasem brzydkie programy z piękną architekturą (MVC, ofcoz) :),

2) Czynnik ludzki. Ogólnie, kryzys w informatyce dzisiaj polega na nieradzeniu sobie umysłu ludzkiego ze złożonością dużego oprogramowania. Po prostu umysł pracuje przeważnie w kategoriach zachłannej optymalizacji (czyli stosuje rozwiązania w danej chwili "dobre" a w ogólności być może złe). Dobry programista (poprawnie stosujący OOP, OOD) też nie jest gwarancją powodzenia dużego projektu. Za dużo jest w takim projekcie parametrów, aby to ogarnąć jednym umysłem.

Temat: Wzorzec MVC i orientacja na model dziedziny

Tomasz Krzal:
2) Czynnik ludzki. Ogólnie, kryzys w informatyce dzisiaj polega na nieradzeniu sobie umysłu ludzkiego ze złożonością dużego oprogramowania. Po prostu umysł pracuje przeważnie w kategoriach zachłannej optymalizacji (czyli stosuje rozwiązania w danej chwili "dobre" a w ogólności być może złe). Dobry programista (poprawnie stosujący OOP, OOD) też nie jest gwarancją powodzenia dużego projektu. Za dużo jest w takim projekcie parametrów, aby to ogarnąć jednym umysłem.

Dokładnie tak, dlatego rośnie we mnie wiara w OOA i OOD w metodykach komponentowych. Na etapie analizy już szatkuje projekt na komponenty z interfejsami (pakiety) mające do kilkunastu klas.... spotykam już w literaturze opisy praktyków (np. Yourdon, Graham, inni) opisów radzenia sobie z rosnąca złożonością projektów: podział na takie komponenty by jeden programista mógł taki komponent zrozumieć i zakodować... robie to od niedawna i uwżam, że ma to sens... tak są już budowane aplikacje m.in. OpenSouce np. wiele CMSów jest tak zrobionych.

Temat: Wzorzec MVC i orientacja na model dziedziny

Co do separacji prezentacji (MVC jest jedną z metod, polecam artykuł Fowlera) w aplikacjach klasy desktop to przypominają mi się moje dawne zabawy narzędziami Borlanda (do Delphi i C++). Po dodaniu komponentu patrzę i myślę sobie: ale fajnie, mogę od razu dodać kod obsługujący. I lądowało tam wszystko, łącznie z operacjami I/O. Inny komponent (teraz to chyba nazywa się kontrolką, czy widżetem) który odpowiadał za taką samą (lub podobną) funkcjonalność. I co teraz - kopiować kod? Szybko okazało się, że trzeba zmodelować problem (chyba to był player mp3), a w kontrolkach jedynie wywoływać metody z modelu.

Powyższy przykład pokazuje, że problem nie leży w graficznych ułatwiaczach, ale w odpowiednim ich wykorzystaniu. Nic nie zastąpi myślenia w pracy projektanta/programisty.

Co do programowania komponentowego (jako rozwinięcie OOP) to ma ono przed sobą przyszłość. Widać to dobrze na przykładzie wspomnianych narzędzi Borlanda, posiadających potężny zestaw gotowych komponentów. Innym dobrym przykładem są konsolowe aplikacje (tak popularne w systemach *nix) i graficzne nakładki do nich. Dzięki komponentom i dobrym interfejsom komunikacji każdy może zająć się tym co akurat potrzebuje/lubi.