Gościem drugiego odcinka DevTalk jest Basia Fusińska – programistka, “architektka”, menadżerka, trenerka…
Rozmawiamy głównie o AOP – Aspect Oriented Programming – programowaniu aspektowym. Basia opowiada o swoich bojach na tym polu i przedstawia dostępne techniki oraz narzędzia przydatne dla adeptów tej sztuki. Udowadnia też, że i TY używasz aspektów!
Uwaga: dzięki uprzejmości producenta narzędzia PostSharp – do wygrania licencja na PostSharp Ultimate o wartości 749$! Szczegóły w odcinku i na stronie http://devtalk.pl/konkurs-na-logo/.
Uwaga 2: ten (i “hopefully” kolejne też) odcinek został nagrany na profesjonalnym sprzęcie (mikrofon + mixer) użyczonym przez Roberta, właściciela firmy Ultrico. Dzięki!
Uwaga 3: wszelkie uwagi – czy to do technikaliów, czy do merytoryki – bardzo mile widziane, zostawiajcie komentarze! :)
Montaż odcinka: Krzysztof Śmigiel.Ważne adresy:
- zapisz się na newsletter
- zasubskrybuj w iTunes, Spotify lub przez RSS
- ściągnij odcinek w mp3
Linki do materiałów omawianych w odcinku:
- Basia na dotnetconfpl: “Programowanie zorientowane aspektowo (AOP)” (https://www.youtube.com/watch?v=es_qdXKSh7M)
- PostSharp (http://www.postsharp.net)
- Gael Fraiteur (twórca PostSharp) o AOP z Zine Day 2008 (sic!), BARDZO polecam (https://vimeo.com/2116491)
- Znowu Gael na ZineDay 2008, tym razem w parze z Jakubem Binkowskim (https://vimeo.com/2387616)
- Fody (https://github.com/Fody/Fody)
- Slajdy z prezentacji Pawła Łukasika o Fody (http://slides.com/pawellukasik/fody#/)
- Nagranie video z prezentacji Pawła Łukasika o Fody (https://www.youtube.com/watch?v=Lc1pQ-mCyys)
- Autofac Interceptors (https://code.google.com/p/autofac/wiki/DynamicProxy2)
- Policy Injection Application Block (http://msdn.microsoft.com/en-us/library/ff664572(v=pandp.50).aspx)
- Code Contracts (http://msdn.microsoft.com/en-us/library/dd264808(v=vs.110).aspx)
- książka Matthew D. Groves “AOP in .NET” (http://www.manning.com/groves/)
Muzyka wykorzystana w intro:
“Misuse” Kevin MacLeod (incompetech.com)
Licensed under Creative Commons: By Attribution 3.0
http://creativecommons.org/licenses/by/3.0/
Dobra realizacja, świetny temat i gość :) Jedyne czego mi zabrakło to po skończonej rozmowie z gościem takiego podsumowania odcinka z twojej strony, może jakiejś małej zapowiedzi co w następnym, takiego swoistego rozstania się ze słuchaczami. Zmieniłbym bym także jingla na ogłoszenia ;)
Pozdrawiam i do usłyszenia!
Grzegorz,
Dzięki :).
Co do “outro” to faktycznie dobry pomysł, teraz to się urywa niespodziewanie. Pomyślę i od następnego razu postaram się coś takiego przygotować.
Co do zapowiedzi kolejnego odcinka – to jest na tyle młode i żywe że jeszcze nie miałem zaplanowanego następnego nagrywając ten. Teraz są w kolejce już dwa, ale w sumie i tak nie wiem czy będę chciał przed czasem zdradzać kto/co/o czym.
A “devgłoszenia”… pierwotnie miało być “ogłoszenia devpasterskie” więc i tak znalazłem półśrodek ;). Chyba że chodzi o sam dźwięk – jeśli tak to się zgadzam, finalnie *prawdopodobnie* będzie coś innego.
Profesjonalnie!
Nie wiem, czy to zasługa tych specjalistycznych mikrofonów i mikserów… Ale macie piękne głosy! :)
Rafał, thx, się prawie zarumieniłem. Zaraz podeślę komentarz Basi to ona też się prawie zarumieni ;).
Ja również nie widzę za bardzo zastosowań dla PostSharp. Zwłaszcza jeżeli kosztuje tyle ile kosztuje :) Można by się zastanowić nad użyciem tego, ale za darmo. Rzeczy, które daje i są naprawdę użyteczne, można mieć za darmo z wykorzystaniem kontenera.
Nie zgodzę się też ze słowami Twojego gościa co do minusów wykorzystania kontenerów do implementacji aspektów. W PostSharp też nie dodaje się atrybutu do każdej z metod każdej z klas (to byłoby straszne), żeby np. dodać logowanie. Również robi się to globalnie, czyli również “nie widać tego” i można o tym zapomnieć.
Nie rozumiem również jak dekoratory łamią SRP?
Piotr,
Thx za komentarz, gdyby każdy się z każdym zgadzał to by było strasznie nudno :).
Co do logowania to Basia mówiła i u mnie i na dotnetconf, że to scenariusz przydatny tylko podczas demonstracji. Jestem skłonny się zgodzić.
A dekoratory i SRP – siłą rzeczy DODAJĄ one odpowiedzialność do jakiejś klasy poprzez opakowanie jej w inną klasę, ale… też bym nie powiedział że łamią SRP, moim zdaniem raczej właśnie szanują SRP poprzez dystrybucję odpowiedzialności do osobnych klas a nie doklepywanie kolejnych rzeczy do klasy oryginalnej. Ale to było spotkanie o AOP :).
Dorzucę swoich 50 centów.
Dużą krzywdę robi się AOP a bardziej AOSD (aspect-oriented software development) mówiąc że nie jest do umieszczania reguł/logiki biznesowych. Skupiliście się na konkretnym sposobie implementacji AOP (wstrzykiwanie, weaving itd konkretnych rozwiązaniach) a nie na samej idei AOSD.
AOP nie jest ograniczony tylko do infrastruktury, problemów technicznych a cross cutting concerns nie oznacza tylko technicznych aspektów jest to moim zdaniem zbyt dużym uogólnieniem. Czasem logowanie zdarzeń może być wymaganiem funkcjonalnym a same wymagania niefunkcjonalne mogą składać się z funkcjonalnych.
CCC mogą być również reguły biznesowe, przecinające wiele domen (core concern). Chyba wszyscy się zgodzimy że ‘Concerns’ jako ‘problem’ powinny być segregowane (separation of concerns) w celu osiągnięcia spójności/skupienia na jedną ‘czynność’ (high cohesion). I nie chodzi tutaj tylko o aspekty techniczne ale również i reguły biznesowe.
Myślę że postrzeganie AOP jako remedium tylko w przypadku ‘infrastruktury’ bierze się stąd że jest to łatwiej zobrazować szerszemu gronu (czasem mniej doświadczonym dev) oraz że zobrazowanie na wymaganiach biznesowych zawsze wymaga wprowadzenie konkretnego kontekstu i opisu domeny co nie jest takie proste.
Dodatkowo reguły biznesowe ulegają częstym zmianą i raz przyjęte rozwiązanie po zmianie wymagań może pociągnąć za sobą konieczność redesignu. Czyli początkowo możemy korzystać z AOP do implementacji jakiś reguł ale po rozbudowie wymagań sensowniejsze/prostsze może okazać się zrezygnowanie z AOP w celu uniknięcia skomplikowania (accidental complexity).
AOP jest najwyższą formą umożliwiającą osiągnięcia loose coupling i wymaga dużej wiedzy na temat modelowanego problemu jak i umiejętności pracy na wysokim poziomie abstrakcji. To IMO powoduje że tak rzadko opisuje się go w ujęciu implementacji reguł biznesowych. Można skorzystać z prostszych rozwiązań eventy, różne patterny (dekorator, mediator itp itd) czy też podejścia architektonicznego CQRS+ event sourcing. Prostsze rozwiązania w dużych systemach mogą się nie sprawdzać z racji że nadal pozostaje powiązanie pomiędzy modułami, problemami (oczywiście to również zależy od sposobu implementacji).
Co do micro-services to polecam http://blog.cleancoder.com/uncle-bob/2014/10/01/CleanMicroserviceArchitecture.html i powiązane artykuły.
Poza tym to fajnie że pojawił się devtalk.
Piotr,
Jasne, ze za pomoca PostSharp mozesz aspekty dodac globalnie. Ale… po pierwsze masz rowniez mozliwosc okreslenia za pomoca atrybutow konkretnych metod. A po drugie, gdy uzywasz kontenera (a przynajmniej Autofac z wtyczka Castle.Windsor, ktorego uzywam w swoim demo), dodaje on aspekt do _kazdej_ metody klasy do ktorej uzywam interceptora.
To, jak testować, to co kod aspektu robi (Testing the advice) w przypadku tkania bibliotek za pomocą narzędzi takich jak Fody, można podejrzeć w projekcie https://github.com/Fody/BasicFodyAddin, w którym napisany jest przykład budowania paczki NuGet, ale przy okazji tam też jest napisany test jednostkowy. W skrócie, nowe, utkane assembly zasysane jest do testów jednostkowych. Tutaj nabazgrałem kilka własnych linijek bazując na tym projekcie: http://teo-vincent.blogspot.com/2014/11/unit-tests-advice-aspect-oriented.html.
1. Dobrze, że na końcu jest rochę Twojego zdania na temat AOP (już myslałem, że go nie wyrazisz)
2. Rozwiń myśl “WCF przeklęty”. Rozważam wpakowanie się w WCF w projekcie “na lata” i na razie nie wiem co mi grozi.
Artur,
Tutaj założenie było takie aby jednak głównie Basia mówiła – ja AOP unikam ze względów raczej “ideologicznych”, nie używałem post#/fody w projekcie prawdziwym. Więc i wypowiadać się jakoś autorytatywnie nie mogę.
WCF: miałem w kilku projektach i ZAWSZE kończyło się to źle. W teorii jest pięknie i ślicznie, niby wszystko ze wszystkim gada, ale jak pojawia się problem to w 90% odpowiedź jest jedna: “ustaw wszystkie tresholdy na max”. Założeniowo WCF jest ok, ale z praktyką jest dużo gorzej (jak to dość często z produktami od MS bywa). Jak się wywali (a się wywali prędzej czy później) to jest bieda bo tak naprawdę nie wiadomo co i dlaczego się stało oraz jak to naprawić poza zwiększaniem po kolei wszystkich limitów na ślepo. I nie są to tylko moje doświadczenia, żeby nie było po prostu jak jestem głupi i coś robiłem źle :).
[…] pisał – można znaleźć na ten temat sporo informacji. Z lokalnego podwórka polecam DevTalk 02 czy tagi AOP lub PostSharp na […]