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:
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.
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 :)
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!
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.
IoC jest oklepane, mi za to sam AOP się podoba. Bardzo :)
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".
Prześlij komentarz