Hej mam pytanie odnośnie encji i logiki biznesowej aplikacji.
Mam w tej chwili w systemie encję produkt która posada cenę oraz walutę w jakiej cena jest podana. W systemie jest też ustawiona waluta podstawowa. W niektórych miejscach potrzebuję przeliczyć cenę produktu na walutę podstawową - czy przeliczenie tej ceny może odbywać się w encji produkt w jakiejś dedykowanej metodzie typu getFinalPriceInBaseCurrancy czy raczej powinno odbywać się to w jakimś innym miejscu systemu?
0
0
W klasie przechowującej informacje o cenie i jej walucie. Poczytaj o wzorcu projektowym Money.
1
W encjach nie implementujemy logiki biznesowej. Od tego są klasy z wyższych warstw, które na encjach operują, a nie same encje.
2
@grzesiek51114 ale czym dla ciebie jest "encja"? Bo w rozumieniu DDD (czyli to o co pytał autor) encja to obiekt domenowy i z definicji ma zawierać logikę biznesową. Ale np. w javie stosuje sie taką nazwę też dla klas @Entity które są klasami mapujacymi ORMa i wręcz przeciwnie, nie powinny zawierać logiki, bo powoduje to same problemy.
2
No właśnie - tyle słów na świecie, a w IT dwie sprzeczne rzeczy nazywane są jednym określeniem.
Dlatego ja stosuję rozróżnienie na encje i persistence modele.
0
@Shalom, @somekind: miałem na myśli encję jako obiekt używany przy mapowaniu ORM, bo w zasadzie jest to pierwsze z czym mi się kojarzy.
4
Niektórym wszystko się kojarzy z jednym, ale to forum programistyczne, a nie psychologiczne. ;)
0
Nie, To definicja Rebecca Parson i Josh Mackenzi oraz Martina Fowlera z roku 2000. A samo Presistance model to też wymysł Fowlera tylko że pod nazwą Anemic Domain i wywodzi się bezpośrednio z obiektów używanych przez ORM.
POCO oznacza klasy zdefiniowane wyłącznie za pomocą języka i standardowej biblioteki, niezwiązane z żadnym frameworkiem ani zewnętrzną biblioteką, w szczególności z ORMem. Ta nazwa oznacza to sposób napisania kodu, a nie jej przeznaczenie. Klasy nazywane POCO mogą być zatem używane do różnych celów, i w rożnych kontekstach inaczej się nazywać. Może istnieć Persistence Model napisany jako POCO, ale można też mieć klasy udekorowane atrybutami ORMa, co już POCO nie będzie. Tak więc stawianie równości między tymi nazwami jest nieprawidłowe. ADM też może być POCO, a może nie być.
Persitence Model i Anemic Domain Model to dwie różne rzeczy. Jedna to celowo napisana warstwa obiektów mapowanych na źródło danych, z uwzględnieniem technologii mapującej (np. ORMa albo serializacji XML). Drugie to niepoprawna implementacja Domain Modelu, w której logika zamiast w encjach znajduje się w proceduralnych serwisach. ADM samo w sobie nie ma nic wspólnego z bazą danych.
To, że niektórzy maja ADM i używają tych samych klas jako PM, to nie znaczy, że jakiś Fowler to wymyślił.