Non-anemic entities w projektach bez DDD

Odpowiedz Nowy wątek
2018-08-06 10:43
1

Mam taką encję:

public class Author
    {
        public int Id { get; set; }

        public string FirstName { get; set; }

        public string LastName { get; set; }
        // ....
        public string FullName() => FirstName + LastName;
    }
  1. Czy jeśli nie piszę projektu zgodnie z DDD, to mogę umieścić w kodzie tej encji metodę FullName?
  2. W tym artykule autor sugeruje, żeby logikę niektórych akcji związanych ze zmianą stanu encji umieszczać bezpośrednio w encji (metoda Publish z encji BlogPost). Czy takie mieszanie podejść projektowania aplikacji jest w porządku?
Pokaż pozostałe 3 komentarze
Jako że @Visual Code zmodyfikował swój komentarz po tym, jak już się do niego odwołaliśmy, tutaj oryginalna treść: O właśnie do takich pytań powinny być łapki w dół.. - Patryk27 2018-08-06 14:44
Jeśli komentarz został edytowany to nie ma się już do czego odwoływać, widocznie autor stwierdził, że jest nieaktualny. Dlatego proszę uszanować moje prawo do edycji komentarza i usunąć zacytowaną treść. - Visual Code 2018-08-06 14:47
@Visual Code: to tak nie działa, a edytowanie komentarzy to co do zasady trolling. - somekind 2018-08-06 14:49
Nie rozumiem, komentarz został edytowany, bo niechcący napisałem w dół zamiast w górę. Jeżeli jest to zabronione proszę usunąć tę opcję, a nie nazywać to trollingiem. Już jedna rozsądna osoba napisała pod jednym z tematów o tworzeniu sobie własnego regulaminu przez moderatorów. Powoli to forum przestaje mi się podobać @Adam Boduch, proszę cię przyjrzyj się tym moderatorom, rozumiem, że te osoby siedzą tutaj 24/7, ale to nie znaczy, że mogą posiadać władzę absolutną oskarżać, banować bezpodstawnie. - Visual Code 2018-08-06 14:54
@Visual Code: zmiana treści komentarzy gdy już ktoś na nie odpowiedział, zaburza sens dyskusji i sprawia, że robisz głupców z opowiadających. To co pierwotnie napisałeś było krytyką pytania, potem zmieniłeś treść na chwalącą, to wygląda jak próba siania flejmu. Takich efektów można by uniknąć, gdybyś po prostu napisał nowy komentarz. Dlaczego tego nie zrobiłeś? - somekind 2018-08-06 15:11

Pozostało 580 znaków

2019-07-24 13:52
1

Co nie zmienia faktu, że jak masz klasy z właściwościami i do tego zewnętrzne "serwisy" operujące na tychże, razem z zewnętrznymi walidatorami i diabli wiedzą czym jeszcze, to nie jest to obiektówka, tylko oranie procedurami po strukturach.

I tak, zgadzam się, że należy testować. Ale łatwiej przetestować zachowanie jednego obiektu niż tworzyć 4, żeby wykonać jedną prostą operację. A potem ktoś sprzęgnie serwis na twardo z bazą i zaczynasz połowę operacji mockować, bo jest szybciej i łatwiej, w efekcie testując mocki albo walisz integracyjne...

Zwyczajnie łatwiej zrobić dziadostwo moim zdaniem.

Pozostało 580 znaków

2019-07-24 13:58
0

To, ze to nie jest do konca obiektowe, nie znaczy od razu, ze jest zle. W DDD do serwisow aplikacyjnych tez trzeba pisac testy, bo ta walidacja w encjach jest tylko na wszelki wypadek, gdyby warstwa aplikacji zawiodla. Roznica jest taka, ze przy TS nie mamy duplikacji kodu i nic nie wnoszacych wrapperow na ORMa.

Pozostało 580 znaków

2019-07-24 14:03
1

A to ja nie mówię, że od razu złe, tylko że łatwiej się zaplątać moim zdaniem. I nie tyle "nie do końca obiektowe" co zwyczajnie proceduralne, bo "zachowanie" jest oderwane od danych, więc nie masz obiektów, tylko struktury i procedury operujące na tychże.

Pozostało 580 znaków

2019-07-24 14:23
0

Ok, niech ktoś pokaże duży projekt napisany zgodnie z DDD (albo obiektowo, jak ktoś nie chce buzzwordów).

Pozostało 580 znaków

2019-07-24 16:30
0

Masz chciałeś jakiś większy projekt dobrze zrobiony w DDD https://github.com/VaughnVernon/IDDD_Samples_NET


Pozostało 580 znaków

2019-07-24 17:55
0
nobody01 napisał(a):

Dlaczego tylko przy CRUDzie? Jakiś przykład?

Nie napisałem, że tylko w CRUDzie. CRUD jest przykładem czegoś, do czego DDD nie ma zastosowania.

Nie rozumiem, przecież w testach sprawdzę, czy walidacja operacji przebiega poprawnie, więc w czym problem?

W tym, że testy nie sprawdzą, czy programista wywołuje tę walidację zawsze podczas majstrowania przy obiekcie.

nobody01 napisał(a):

No chyba taki jest cel walidacji - sprawdzenie poprawnosci danych wejsciowych i mozliwosci wykonania operacji.

Owszem - danych wejściowych. Podczas wykonywania logiki biznesowej, nie operujesz na danych wejściowych tylko na regułach/przepływach biznesowych.

nobody01 napisał(a):

Ale ja tu caly czas pisze, ze takie rzeczy mozna i trzeba testowac.

Podobno można też pisać w językach dynamicznie typowanych i zastąpić system typów testami.

nobody01 napisał(a):

To, ze to nie jest do konca obiektowe, nie znaczy od razu, ze jest zle. W DDD do serwisow aplikacyjnych tez trzeba pisac testy, bo ta walidacja w encjach jest tylko na wszelki wypadek, gdyby warstwa aplikacji zawiodla.

Oj nie, Ta walidacja służy do czegoś zupełnie innego.

Roznica jest taka, ze przy TS nie mamy duplikacji kodu i nic nie wnoszacych wrapperow na ORMa.

Bynajmniej. To w projektach opartych o TS jest masa niczego nie wnoszących wrapperów. W DDD nie ma takich, tylko projektów w DDD nie ma.


"HUMAN BEINGS MAKE LIFE SO INTERESTING. DO YOU KNOW, THAT IN A UNIVERSE SO FULL OF WONDERS, THEY HAVE MANAGED TO INVENT BOREDOM."

Pozostało 580 znaków

2019-07-24 18:43
1

Oj nie, Ta walidacja służy do czegoś zupełnie innego.

Można powiedzieć, że jest to forma walidacji, ale tak naprawdę nie chodzi o walidację tylko o kontrakt. Według mnie nie powinno się tego nazywać walidacją. Nazywanie tego walidacją rodzi pewnego rodzaju problem logiczny typu "a po co mi dwie walidacje...."

Bynajmniej. To w projektach opartych o TS jest masa niczego nie wnoszących wrapperów. W DDD nie ma takich, tylko projektów w DDD nie ma.

DDD nie mówi nic o tym, że nie możesz używać takich komponentów, jakie ci się podobają w warstwie Applikacji, jeśli o to ci chodzi. To że ktoś pakuje coś w wrapa i nie wie poco to jego problem.


Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0