пропозиції роботи
konto usunięte
Temat: Budowa Frameworków
Wojciech Soczyński:
Można by sprowadzić propela do roli infrastruktury a całą logikę wyekstrahować do klas usługowych i encji.
Ja tak robię i polecam ;-)
Ja tak robię i polecam ;-)
Alan Gabriel
B.
Software Engineer,
IFX
Temat: Budowa Frameworków
Wojciech Soczyński:
Widocznie nie wyczułem intencji twojej wypowiedzi. Jeżeli chodzi o dokończenie projektu zaczętego z propelem a kończeniem go w DDD to myślę, że najlepiej sprawdzi się tu stara mantra: "każdy problem w informatyce można rozwiązać dodając kolejna warstwę abstrakcji" ;).
Zresztą podejście Active Recordowe nie różni się aż tak bardzo od podejścia Data Mapper + DDD. W zasadzie główna różnica jest taka, że przy Data Maperze obiekty są utrwalane, a w Active Record utrwalają się same.
I ja wciąż uważam, że przepisujesz, a nie refaktoryzujesz :] Tracisz wtedy integralność na której refaktoryzacja się opiera.
Można by sprowadzić propela do roli infrastruktury a całą logikę wyekstrahować do klas usługowych i encji.
I tu jest pies pogrzebany, bo przy dużym upakowaniu logiki biznesowej w obiektach Propela, to byłaby mordercza praca i marnotrawstwo potencjału, który w Propelu drzemie(bo każde narzędzie ma swoje wady, zalety i właściwe zastosowanie).
Pisałem kiedyś projekt w którym robiłem podobnie. Sęk w tym, że to tak było zaplanowane od samego początku, a nie w wyniku przenoszenia logiki biznesowej pomiędzy warstwami.
Jedyną różnicą z zaproponowanym przez Ciebie rozwiązaniu było to, że moje encje w tamtym projekcie były klasami bazowymi dla obiektów Propela (to było sprytne, aczkolwiek małe wypaczenie w warstwie dziedziny, ale wtedy dopiero poznawałem DDD), natomiast u Ciebie - zakładam - dochodziłby etap przepakowywania encji do obiektów Propela (poprawnie wg ideologii DDD, ale równie kulawe jak np. często spotykane pobieranie encji w repozytoriach i późniejsze przepakowywanie ich do DTO, zamiast pobranie DTO bezpośrednio ze źródła danych).
W rezultacie mógłbyś zupełnie pozbyć się Propela, a przecież nie o to chodzi. Nie w kontekście tego, co chcę udowodnić, że w projektach np datacentrycznych nie ma mowy o ewolucji do DDD, jest tylko przepisanie od nowa poprzez rozpoczęcie projektu na nowo lub mozolne wykluczenie niechcianych elementów.
P.S. W poście, który podałem w linku, to co nazywam modelem obejmuje encje, ale również implementację repozytoriów (poznawałem dopiero terminologię).
Wojciech
Soczyński
Programista
eksplorator -
blog.wsoczynski.pl
Temat: Budowa Frameworków
Właśnie dzięki zastosowaniu interfejsów, zachowujemy integralność refaktoryzacji, ponieważ zmieniamy tylko implementacje.Zresztą nie będę się upierał przy swoim zdaniu. Jeżeli sprawdziłeś to w praktyce i tak rzeczywiście jest to oczywiście masz rację.
Jak zawsze powtarzam, wszystko zależy od konkretnego przypadku, czasami bardziej opłaca się przepisać wszystko od nowa a czasami refaktorować.
Ważne jest przede wszystkim, żeby konsekwentnie trzymać się planu jaki się powzięło. Jeżeli dobrze zwarstwujemy naszą aplikacje i będziemy się tego trzymać. To nawet przy dużych zmianach w jednej warstwie reszta będzie mogła pozostać nienaruszona.
konto usunięte
Temat: Budowa Frameworków
Wojciech Soczyński:
Jak zawsze powtarzam, wszystko zależy od konkretnego przypadku, czasami bardziej opłaca się przepisać wszystko od nowa a czasami refaktorować.
Tez mialem takie zdanie. Kilka lat temu. Dzis twierdze, ze po prostu nie wiedzialem, ze refaktoryzacja to zbior skilli i jesli cos jest za trudne do refaktoryzacji, to jest to po prostu wyzwanie. Z takiego wyzwania rodza sie nowe skille i nowe zrozumienie.
Refaktoryzacja i porzadek (wzorce) ida ze soba w parze. Jedno uczy drugiego.
Artur Świerc Programista PHP/Java
Temat: Budowa Frameworków
Panowie, skąd czerpaliście wiedzę na temat DDD? Faktem jest że w C# robi furorę, w phpie mało o tym słychać (był nawet zaczęty wątek na ten temat - przepadł w zapomienie), dlatego może też mało kto teraz może z Wami podyskutować. Czy jesteście w stanie podać jakieś phpowe przykłady i napisać coś dla ludzi zapoznających się z tą metodologią?Pozdr.
Alan Gabriel
B.
Software Engineer,
IFX
Temat: Budowa Frameworków
Z książek głownie :) To tak jak z OOP, trzeba czytać i próbować, aż się załapie idee.Kilka postów wcześniej podałem 3 pozycje traktujące bezpośrednio o DDD + jedna o wzorcach projektowych (ważna część DDD) od M. Fowlera.
edit
Zapomniałbym, bardzo pomogły blogi, szczególnie tego Pana, oraz prezentacje i inne materiały udostępnione przez InfoQAlan Gabriel B. edytował(a) ten post dnia 25.05.10 o godzinie 13:16
Wojciech
Soczyński
Programista
eksplorator -
blog.wsoczynski.pl
Temat: Budowa Frameworków
Ja wiedzę czerpię głównie z blogów, polecam http://giorgiosironi.blogspot.com/ , facet jest kumaty i się dość dobrze zna na tym. Trochę też jest na blogu głównego architekta Zend Frameworka http://weierophinney.net/matthew/.Ogólnie nie jest prawdą, że o DDD w PHP-ie nic się nie dzieje. Może w Polsce nic, ale na zachodzie jest dość duży szum. Wystarczy zanurkować w angielskojęzyczną blogosferę. Polecam subskrypcje http://planet-php.net/.
Zamierzam też coś napisać niedługo w kontekście DDD na moim blogu.
Alan Gabriel
B.
Software Engineer,
IFX
Temat: Budowa Frameworków
Poszperałem trochę w RSSach i wyskoczyło mi kilka blogów które traktują o DDD wprost lub pośrednio:Debasish Ghosh
Jimmy Bogard
Wspomniany powyżej Giorgio Sironi
Federico Cargnelutti
Sławek Sobótka
Tomasz Zadora programuję
Temat: Budowa Frameworków
Jeżeli ma się czas i chęci warto budować swój własny framework. To zawsze zaprocentuje w przyszłości - chociażby tym, że we własnym frameworku aplikacje i aktualizacje aplikacji pisze się *szybko*, bo zna się go od podszewki.Są też minusy: np. jeżeli z kimś współpracujesz (nowym) - musisz taką osobę tego frameworku nauczyć. Od strony klienta minusem jest fakt, że jest do Ciebie trochę przywiązany - o wiele łatwiej jest zastąpić Ciebie kimś innym jeżeli aplikacja jest w ZENDZie/Symphony etc. niż w sytuacji kiedy tego frameworku nikt nie zna.
Przy okazji: framework ma realizować ideę DRY (Don't Repeat Yourself - nie powtarzaj się), tworzy się go po to aby nie powtarzać ciągle tych samych czynności w podobnych projektach.
Czasem ten cel można osiągnąć nie koniecznie budując cały framework ale bazując na snippetach, kopiowaniu części kodu ze starszych aplikacji etc.
konto usunięte
Temat: Budowa Frameworków
Nie wiem czy ktoś tu już wspominał o tym, ale skoro mowa o DDD to warto też wspomnieć o ADD i CYAE. To są bardzo ważne metodologie i przyznam, że widziałem jak z sukcesem się je stosuje.
konto usunięte
Temat: Budowa Frameworków
Piotr Likus:
Nie wiem czy ktoś tu już wspominał o tym, ale skoro mowa o DDD to warto też wspomnieć o ADD i CYAE. To są bardzo ważne metodologie i przyznam, że widziałem jak z sukcesem się je stosuje.
^^
tak z ciekawosci, w ktorej z firm z Twojej listy sa one najpopularniejsze?
konto usunięte
Temat: Budowa Frameworków
Tomasz Zadora:
Czasem ten cel można osiągnąć nie koniecznie budując cały framework ale bazując na snippetach, kopiowaniu części kodu ze starszych aplikacji etc.
to podstawa, koła na nowo się nie wynajduje :)
konto usunięte
Temat: Budowa Frameworków
Tomasz Grzechowski:
Piotr Likus:
Nie wiem czy ktoś tu już wspominał o tym, ale skoro mowa o DDD to warto też wspomnieć o ADD i CYAE. To są bardzo ważne metodologie i przyznam, że widziałem jak z sukcesem się je stosuje.
^^
tak z ciekawosci, w ktorej z firm z Twojej listy sa one najpopularniejsze?
:D
Wojciech
Soczyński
Programista
eksplorator -
blog.wsoczynski.pl
Temat: Budowa Frameworków
Przemysław R.:Koło wynajduje się ciągle na nowo, bo każdy ma inne spojrzenie na te same rzeczy :>
Tomasz Zadora:Czasem ten cel można osiągnąć nie koniecznie budując cały framework ale bazując na snippetach, kopiowaniu części kodu ze starszych aplikacji etc.
to podstawa, koła na nowo się nie wynajduje :)
Adam Brodziak PHP, football, fun
Temat: Budowa Frameworków
Wojciech Soczyński:I każde kolejne jest bardziej okrągłe :) Tak, w ten sposób się uczymy. Nie tylko pojedyńczy ludzie, ale całe zespoły. Weźmy takie Symfony które jest przepisane od nowa żeby rozwiązać problemy architektoniczne. To samo Doctrine (zmiana głównego wzorca z Arctive Record na Data Mapper). Sami twórcy, PHP się uczą: ostatnio jak działają closures i namespace'y.
Przemysław R.:Koło wynajduje się ciągle na nowo, bo każdy ma inne spojrzenie na te same rzeczy :>
to podstawa, koła na nowo się nie wynajduje :)
Kwestia jest taka, że w PHP jest to łatwo zrobić. Kod da się szybko przepisać i wypuścić. Nikt nie będzie płakał, bo nie ma aplikacji klasy enterprise, które trzeba utrzymywać przez dekady. Tak samo jest z pojedyńczymi programistami wynajdującymi koło od nowa, jedynie skala jest mniejsza.
konto usunięte
Temat: Budowa Frameworków
Adam Brodziak:
I każde kolejne jest bardziej okrągłe :) Tak, w ten sposób się uczymy. Nie tylko pojedyńczy ludzie, ale całe zespoły. Weźmy takie Symfony które jest przepisane od nowa żeby rozwiązać problemy architektoniczne.
Nie zupełnie, prawie wszystkie komponenty Symfony były pisane nie od zera. Naprzykład, kontroler to Mojavi, ORM to był początkowo Propel, szablony to PHP. Po prostu napisali parę jeszcze klas do zintegrowania już gotowych rzeczy, po czym raz za razem tylko dowodzili to wszystko do unifikacji.
Żeby pisać coś od zera, potrzebne jest porządne, skrupulatnie dobrane zero, inaczej koło wyjdzie trójkątem i do tego krzywym.
konto usunięte
Temat: Budowa Frameworków
Piotr Likus:
Tomasz Grzechowski:
Piotr Likus:
Nie wiem czy ktoś tu już wspominał o tym, ale skoro mowa o DDD to warto też wspomnieć o ADD i CYAE. To są bardzo ważne metodologie i przyznam, że widziałem jak z sukcesem się je stosuje.
^^
tak z ciekawosci, w ktorej z firm z Twojej listy sa one najpopularniejsze?
:D
widze, ze mocno politycznie odpowiedziales ;-)
hehe
Adam Brodziak PHP, football, fun
Temat: Budowa Frameworków
Jarosław Fedewicz:Wiem o tym że symfony integruje inne komponenty, ale to właśnie "parę klas do zintegrowania" w Symfony2 jest zrobione od zera. I bardzo dobrze - może coś z tego będzie.
Nie zupełnie, prawie wszystkie komponenty Symfony były pisane nie od zera. Naprzykład, kontroler to Mojavi, ORM to był początkowo Propel, szablony to PHP. Po prostu napisali parę jeszcze klas do zintegrowania już gotowych rzeczy, po czym raz za razem tylko dowodzili to wszystko do unifikacji.
Podobne tematy
Następna dyskusja:
