wtorek, 15 lutego 2011
Naturalny porządek refaktoryzacji - idea rysunkowa
Subskrybuj:
Komentarze do posta (Atom)
Technical Leadership Book
Technical Leadership book is available
It is a great pleasure for me to share the information that today is my "Technical Leadership" book premiere. You can buy it fr...
Mariusz Sieraczkiewicz
Hire me! Write to m.sieraczkiewicz <[AT]> bnsit.pl
Whats Hot This Week
-
The timeboxing is a fundamental technique for many Scrum activities. I can see a misunderstanding that meeting should be fast, a facilitator...
-
Dalszym krokiem, na dużo wyższym poziomie abstrakcji i wymagającym dogłębnego zrozumienia systemu. Na bazie pojawiających się wzorców, ro...
-
Intro You might have already come across terms such as complex systems, complicated systems or complex adaptive systems; especially, if... -
Być może wcześniej miałeś do czynienia z pojęciami typu systemy złożone, skomplikowane, złożone systemy adaptacyjne na przykład przy okazji... -
I have recently came across a very interesting article about pitfalls of Polish style of management and its historical roots . It is more g... -
I have recently came across this beautiful infographics from +Anna Vital I have been a productivity fun for ages but my approach evol... -
Blogspot niestety rozczarowuje mnie pod kątem publikowania kodu źródłowego, co jest szczególnie ważne w przypadku tematów poruszających styl... -
I have been reading a book on a fathership recently (yep, tech guys also read such books :-)) and there has been a discussion about respon... -
Tutaj możesz pobrać wersję PDF artykułu Ze względu na problemy z formatowaniem kodu w blogspot artykuł ten warto przeczytać w formie pliku P...
-
Kiedy myślę sobie o różnych problemach, z którymi zmagają się organizacje, szczególnie o powtarzających się problemach, to zdecydowanie ...
My company
2 komentarze:
Dobra wizualizacja.
Zwrócił bym tylko uwagę, na to, że w *niemałym* projekcie warto rozróżnić warstwy od mvc.
MVC mieszka sobie w warstwie prezentacji jako wzorzec organizowania właśnie prezentacji. Kontroler nie powinien zawierać logiki aplikacyjnej a jedynie logikę związaną z jakąś konkretną technologią prezentacji (nawigacja, ew. specyficzne komunikaty dla konkretnej technologii widoku).
Natomiast w warstwach poniżej możemy sobie ułożyć kolejno:
- logikę aplikacji (serwisy opisujące kroki use case)
- logikę biznesową (model domeny)
- infrastrukturę (dostęp do danych, serwisy techniczne)
Dzięki temu można dowolnie zmieniać technologię prezentacji - np na nasze serwisy aplikacyjne nałożyć web serwisy, remoting, androida idp...
Jest to oczywiście mało prawdopodobne, ale przekonywujący powinien być fakt, że taką logikę aplikacji niezbrukaną konkretną technologią prezentacji (czego nie unikniemy w kontrolerach) można po prostu łatwiej testować.
Kolejna uwaga, to: M z mvc to nie musi być to samo co model domenowy w *niemałych* aplikacjach. Zwykle model domenowy to jedna rzecz, a to co chcemy wyświetlić w danym use case na ekranie to inksza inkszość. Do tego mając rich model (do czego doprowadzi refaktoring) dojdziemy do pewnej niezręczności: dostęp do metod biznesowych na widoku.
Taki model domenowy może być też obarczony np pośrednikami JPA. Przesłanie go do zdalnego klienta to porażka.
Zapomniałem dodać, że pisząc o modelu domeny w warstwie logiki biznesowej (nie aplikacyjnej) miałem na myśli w szczególności Rich Domain Model (np taki z DDD, złożony z 7 różnych klocków, nie tylko encji).
Nie chodzi bynajmniej o to aby odzierać model z logikę biznesowej i przenosić do do warstwy logiki aplikacyjnej.
Aczkolwiek istnieją inne podejście, gdzie mamy jedną warstwę logiki (serwisy) oraz anemiczny model encji.
Prześlij komentarz