wtorek, 10 sierpnia 2010

Pomożecie?


Dzisiejszy post jest nietypowy, ponieważ zwracam się w nim do szanownego grona czytelników z prośbą o pomoc/przysługę. Zostałem zaproszony na tegoroczną konferencję JDD w roli prelegenta i zastanawiam się nad tematem, który mógłby Was potencjalnie (nawet jeżeli nie wybieracie się na konferencję, po prostu ogólnie) zainteresować.

Prezentacja poświęcona Software Craftsmanship i Wzorcom już osiągnęła limit reużywalności, dlatego zastanawiam się nad nowym tematem:) Jeżeli macie jakieś sugestie lub konkretne życzenia odnośnie tego o czym chcielibyście usłyszeć to piszcie śmiało w komentarzu lub na priv (adres w panelu "o mnie" po prawej stronie).

//===============================

Patrząc na ogólne trendy, które w tym roku widać również na polskich konferencjach, można zaobserwować, że raczej odchodzi się od zachwalania kolejnych tuzinów frameworków webowych w stronę zagadnień bardziej ogólnych, zwykle syntetyzując przekrój kilku aspektów. Ciekaw jestem co myślicie o tym trendzie.

Póki co mam pewien pomysł na prezentację poświęconą podejściom do Inversion of Control. Tak, wiem, że temat jest oklepany ale co powiecie na przegląd architektur aplikacji opartych o IoC. Przegląd będący swego rodzaju wycieczką po rozwiązaniach architektonicznych.

Najpierw zastanowilibyśmy się czym w ogóle jest architektura, jakie są jej rodzaje i czym arch. różni się od designu. Później wycieczka po kolejnych podejściach do architektur opartych o 3 techniki IoC w kolejności ich "siły".

Czyli najpierw "najsłabsze" (w sensie siły a nie w sensie, że jest kiepskie) podejście: wstrzykiwanie zależności - co i kiedy warto wstrzykiwać. Bo wstrzykiwanie DAO/Repo do Servisów jest nudne.

Dalej technika "mocniejsza" - bo abstrahująca nie tylko od typu współpracownika, ale i ich ilości oraz czasu - arch. zorientowana na zdarzenia. Przykłady wykorzystania zdarzeń do zwiększania przepustowości oraz do notowania "wydarzeń" biznesowych - wszystko w kontekście event sourcing i Command-query Responsibility Segregation.

Na zakończenie najsilniejsza technika IoC: Aspect Oriented Programming.

Na każdym "przystanku" naszej wycieczki zastanowilibyśmy się co wynika z zastosowania danego podejście i kiedy warto z niego skorzystać - a kiedy jest to tylko moda i owczy pęd.

Jak widać z opisu prezentacja była by przeznaczona dla początkujących architektów aplikacji - programistów, którzy chcieliby zając się projektowaniem w skali makro.

6 komentarzy:

janekw pisze...

Twój pomysł brzmi rewelacyjnie. Wiem że tak najłatwiej z mojej strony, ale to prawda :) Mam nadzieję że uda mi się tego w końcu posłuchać. Pzdr. i do zobaczenia.

Anonimowy pisze...

A może coś przewrotnie o antywzorcach i o nienadużywaniu wzorców. Może pokazać w jakich sytuacjach nie ma sensu stosowac loc di fabryk mvp i innych.

Miałem okazję oglądać kod aplikacji, w której wrzucono chyba wszelkie możliwe wzorce jakie autor znał. Wyglądało to gorzej niż aplikacje pisane na 2 roku studiów. O czytelności nie wspominam :)

Unknown pisze...

Dla mnie najciekawiej brzmi temat o event sourcingu, ale IoC też mogłoby być. Z obu tematów najbardziej interesują mnie Twoje refleksje nt. stosowalności - kiedy zdecydowanie tak, a kiedy raczej tak, raczej nie lub zdecydowanie nie - i dlaczego. Pozdrawiam!

Sławek Sobótka pisze...

Dzięki za feedback panowie. Cieszę się, że zaproponowany temat przypada do gustu co najmniej dwóm osobom:)

@Anonimowy - kiedyś przez chwilę myślałem o tym, ale ogólnie negatywna retoryka nie jest tym co trafia do szerokiego grona odbiorców (choć sam ją lubię:)

Termin zgłoszeń mija w niedzielę, więc zachęcam do komentarzy.

Anonimowy pisze...

IoC jest oklepane, mi za to sam AOP się podoba. Bardzo :)

Sławek Sobótka pisze...

I tak i nie;P
Pierwsze primo: dla kogoś kto dopiero zaczyna nic nie jest dostatecznie oklepane - a taki target przyjąłem obserwując przekrój uczestników konferencji.

Drugie primo: IoC to tak jak napisałem 3 różne techniki o różnej "mocy". O ile w Dependency Incjection nic ciekawego się nie dzieje (poza trikami w Springu pozwalającymi projektować eleganckie DDD) to przy zdarzeniach można już "poszaleć" z Distributed DDD i Event Sourcing.

AOP póki co widzę jako dopełnienie tematu ponieważ jego zastosowanie w architekturach aplikacji jest znikome. AOP w architekturach frameworków i platform - owszem, ale to co interesuje developerów (JDD) to raczej chyba arch. aplikacji.
Rozwiń może obszar swoich zainteresować to zastanowimy się nad proporcjami AOP w tych 45 minutach.

Dzięki za głos i odpowiedź na mój "apel".