Nie chodzi mi o diagram lub bazę danych.
Czy to jest po prostu zbiornik, na który się mapuje dane jak DTO, a jeśli tak to jaka różnica jest pomiędzy encją z wartością a DTO?
Dlaczego wszyscy wytykają używanie publicznych seterów rozumiem, że w pewnym sensie mija się to z hermetyzacją danych, ale przecież ustawianie np. 4 atrybutów w konstruktorze może mijać się z czytelnością kodu.
Encja to obiekt biznesowy.
Obiekt to coś, co zgodnie z założeniami OOP łączy w sobie dane i operacje na nich.
Encja to encja. Czyli wiersz w bazie: https://pl.wikipedia.org/wiki/Encja_(bazy_danych)
i http://tomasz.kubik.staff.iiar.pwr.wroc.pl/dydaktyka/RelacyjneBazyDanych/BD-Wyk01-TK.pdf
Encja może mieć unikalność (jeśli wiemy co to normalizacja).
W DDD dodatkowo ma m.in. (o ile wiem) zachowania.
DTO to (najczęściej niemutowalna) struktura danych która nie musi być unikalna i nie ma odzwierciedlenia w bazie. Zwykle nie powinna mieć też zachowań (oprócz akcesorów).
Fowler zawęża znaczenie tego skrótu do struktur które przesyła się między beanami: https://martinfowler.com/eaaCatalog/dataTransferObject.html
A ogólną strukturę wartości określa mianem ValueObject: https://martinfowler.com/bliki/ValueObject.html
Są jeszcze encje w rozumieniu "entity bean" albo JPA - czyli takie cienkie jak opisujesz. O tym też napisał Fowler: https://martinfowler.com/bliki/AnemicDomainModel.html
Encje w trochę lepszym wydaniu Fowler określa jako "Domain Model" i wg niego do ich implementacji najlepiej nadają się POJO. Szczegóły w P of EAA:
http://helion.pl/ksiazki/architektura-systemow-zarzadzania-przedsiebiorstwem-wzorce-projektowe-martin-fowler,szabko.htm
Książka o DDD polecana przez Fowlera: http://helion.pl/ksiazki/domain-driven-design-zapanuj-nad-zlozonym-systemem-informatycznym-eric-evans,domdri.htm
Encja to po prostu "byt". Ten "byt" charakteryzuje się tym że posiada "tożsamość" (np. unikalny identyfikator) i cykl życia (np. taki "nie istnieje"->"istnieje"->"nie istnieje"). Z poziomu kodu źródłowego ciężko mówić o "encji", bo i tak operujemy na abstrakcjach "rzeczywistych" albo "wymyślonych" bytów :)
W zależności od kontekstu, który przyjmiemy (np. analiza strukturalna, analiza obiektowa, ...) encja może być różnie definiowana (np. reprezentacja modelowanego obiektu w przypadku analizy strukturalnej, bądź instancja klasy w przypadku analizy obiektowej).
DTO jak nazwa wskazuje, to po pojęcie z obszaru wzorców projektowych. DTO służą do transferu danych (np. między komponentami, warstwami aplikacji, instancjami klas).
Jeszcze w dyskusji zaplątało się DDD, które jest podejściem do projektowania modelu domenowego, który to model jest jednym z etapów projektowania OO.
pozdr,
y.
@somekind @vpiotr @yarel za dużo naczytaliście się teorii OOP :P Encja (ang.entity) może oznaczać różne rzeczy w różnych kontekstach. Autorowi na oko chodziło raczej o coś w stylu Entity Bean z jakiegoś JPA, które to de facto jest niczym więcej jak właśnie DTO do transferu danych na trasie baza danych <-> aplikacja.
@yarel z tym DDD to bym uważał, bo bliżej już temu do jakiejś religii niż do prostego podejścia do modelowania w OOP ;) Wspomniałem o DDD z tego względu że ma dość mocno sformalizowany słownik pojęć o definicji, co niekoniecznie jest prawdą ogólnie dla OOP.
No właśnie czytając DDD od góry w dół stanąłem na rozdziale z encjami, wartościami i serwisami. Problem polega na tym, że trudno jest mi przełożyć postać abstrakcji do postaci kodu lub sam sobie nie ufam w to, czy dobrze to interpretuje. Czyli każda klasa z niższego poziomu, która musi zawierać jakiś identyfikator jest encją a wartość jest jakby klasą niżej której agregatem jest encja i to encja ją identyfikuje (odpowienikiem w bazie jest np. Post i jego categoria). Oprócz tego encja może wykonywać jakieś przeliczenia porównania lub składania stringów które są podawane do serwisów jako wsparcie dla klasy, która definiuje konkretny model dziedziny a raczej jego część w logice biznesowej np. transakcje bankowe.? Czyli wypadałoby jeszcze z mapować to, co wypluje encja na jakieś DTO?...
Czyli np. jeśli chcę pobrać rekordy z tabeli1 oraz tabeli2 a następnie wykonać na tych rekordach jedynie jakieś obliczenia to trafia to do tej finalnej klasy czy raczej agregatu, czyli transakcje bankowe. Czy wypada jeszcze przepuścić to przez serwis.
Bardzo proszę czy ktoś może wrzucić kod z przykładową implementacją jakiegoś scenariusza biznesowego. Ale realnego, a nie na siłę upraszczanego. Założę się, że na pewno ktoś z was ma coś takiego pod ręką. Chodzi mi o jakiś wycinek logiki biznesowej odpowiedzialny za jedną funkcjonalność.
Shalom napisał(a):
@yarel z tym DDD to bym uważał, bo bliżej już temu do jakiejś religii niż do prostego podejścia do modelowania w OOP ;) Wspomniałem o DDD z tego względu że ma dość mocno sformalizowany słownik pojęć o definicji, co niekoniecznie jest prawdą ogólnie dla OOP.
Może bardziej rozwinąć tę myśl?. Myślałem, że DDD to głównie wykorzystywanie "języka dziedziny biznesowej oraz wszechobecnego" Co ma usprawnić czytanie kodu, oraz komunikację z klientem oprogramowania a programistą.
Shalom napisał(a):
@somekind @vpiotr @yarel za dużo naczytaliście się teorii OOP :P Encja (ang.
entity) może oznaczać różne rzeczy w różnych kontekstach. Autorowi na oko chodziło raczej o coś w stylu Entity Bean z jakiegoś JPA, które to de facto jest niczym więcej jak właśnie DTO do transferu danych na trasie baza danych <-> aplikacja.
OOP to ja akurat praktykuję, a nie czytam o nim. Generalnie obiekt aby był obiektem, musi mieć zachowanie, a encje są z definicji obiektami. To, że twórcy jakichś tam ormów czy innych narzędzi proste modele danych też nazwali encjami może wynikać z tego, że te obiekty przekładają się na encje bazodanowe (czyli wiersze). Nazwa niefortunna, konfundująca i irytująca (przynajmniej mnie).
WebJarek napisał(a):
No właśnie czytając DDD od góry w dół stanąłem na rozdziale z encjami, wartościami i serwisami. Problem polega na tym, że trudno jest mi przełożyć postać abstrakcji do postaci kodu lub sam sobie nie ufam w to, czy dobrze to interpretuje. Czyli każda klasa z niższego poziomu, która musi zawierać jakiś identyfikator jest encją a wartość jest jakby klasą niżej której agregatem jest encja i to encja ją identyfikuje (odpowienikiem w bazie jest np. Post i jego categoria).
Post to encja i kategoria to encja. Oba te byty jesteś w stanie niezależnie identyfikować, nieprawdaż?
Encja może zrealizować jakąś logikę, czyli np. encja pozycja faktury obliczy kwotę (liczba sztuk * cena jednostkowa) netto, a encja faktura obliczy cenę całości (sumując wszystkie swoje pozycje).
Logika wykonywana przez encje nie może wykraczać poza agregat, w którym ta encja się znajduje. W podanym przykładzie agregatem jest faktura i jej pozycje, a faktura to root (korzeń?) tego agregatu.
Jeśli trzeba wykonać jakąś logikę między agregatami, to używa się do tego serwisów.
Oprócz tego encja może wykonywać jakieś przeliczenia porównania lub składania stringów które są podawane do serwisów jako wsparcie dla klasy, która definiuje konkretny model dziedziny a raczej jego część w logice biznesowej np. transakcje bankowe.?
Zupełnie nie rozumiem pytania. Encje są częścią definicji modelu dziedziny, który jest de facto logiką biznesową.
Założę się, że na pewno ktoś z was ma coś takiego pod ręką. Chodzi mi o jakiś wycinek logiki biznesowej odpowiedzialny za jedną funkcjonalność.
Ja bym się o to nie zakładał. Prawdopodobnie nikt nigdy nie napisał niczego realnego zgodnie z DDD. To tylko buzzword.
Shalom napisał(a):
@somekind @vpiotr @yarel za dużo naczytaliście się teorii OOP :P Encja (ang.
entity) może oznaczać różne rzeczy w różnych kontekstach. Autorowi na oko chodziło raczej o coś w stylu Entity Bean z jakiegoś JPA, które to de facto jest niczym więcej jak właśnie DTO do transferu danych na trasie baza danych <-> aplikacja.@yarel z tym DDD to bym uważał, bo bliżej już temu do jakiejś religii niż do prostego podejścia do modelowania w OOP ;) Wspomniałem o DDD z tego względu że ma dość mocno sformalizowany słownik pojęć o definicji, co niekoniecznie jest prawdą ogólnie dla OOP.
@Shalom: To może jeszcze raz przeczytaj moją odpowiedź w kwestii definicji encji w zależności od kontekstu... Zakładasz, że wiesz lepiej od autora o co mu chodziło, ja preferuję wprowadzić wspólny spojrzenie na problem (ustalić wspólny słownik), a dopiero później sformułować pytanie (korzystając z tego słownika) i odpowiedź ;-) Z moich obserwacji wynika, że sporo ludzi nie widzi różnicy między analiza strukturalną i obiektową i zaczynają projektować dziedzinę wychodząc od modelu danych, a później robią z tego diagram klas, albo mówią, że chcą diagram klas, a chodzi im o model dziedziny.
Co do DDD, to nawet nie chcę dyskutować o tym ;-)
yarel napisał(a):
Z moich obserwacji wynika, że sporo ludzi nie widzi różnicy między analiza strukturalną i obiektową i zaczynają projektować dziedzinę wychodząc od modelu danych, a później robią z tego diagram klas, albo mówią, że chcą diagram klas, a chodzi im o model dziedziny.
No i tutaj dobrze mnie wyczułeś jest to efekt webowego programisty PHP gdzie większość aplikacji to apli. "CRUD'owe" mówię oczywiście o sobie ;P
Jaką lekturę możesz mi polecić, która może mi pomóc odnośnie do tego problemu?
Aktualnie odłożyłem DDD i czytam "Microsoft .NET:
Architecting Applications
for the Enterprise,
Second Edition"
WebJarek napisał(a):
..
Jaką lekturę możesz mi polecić, która może mi pomóc odnośnie do tego problemu?
Mogę polecić "UML i wzorce projektowe. Analiza i projektowanie obiektowe oraz iteracyjny model wytwarzania aplikacji." autrostwa Craig'a Larmana. Moim zdaniem bardzo dobre wprowadzenie w tematykę projektowania, pokazujące etapy tworzenia modelu jak i zasady, których dobrze się trzymać (SOLID/GRASP). Jest też trochę o iteracyjnym podejściu do wytwarzania oprogramowania na przykładzie Unified Process.