Mapowanie na Domain Model :: 4programmers.net

MrBean Bean

2017-12-20 20:56

MrBean Bean2017-12-20 20:56

Rejestracja:ponad 7 lat
Ostatnio:ponad 7 lat
Postów:117

Jak powinno się implementować Domain Model wraz z ORM.?
Dużo robi się krzyku o to że setery są be bo "naruszają" enkapsulacje.
Tylko, że nikt nigdy nie mówi o konkretnym bugu, w tej konkretnej sytuacji.

Prosty przykład Encji (bez sensu ale mniejsza o to)

Kopiuj

public class Order : IValidation
    {
        private string _orederAmount;

        public virtual int Id { get; protected set; }
        public virtual string OrederAmount
        {
            get => _orederAmount;
            protected set => _orederAmount = value;
        }
        public ValidationResult ValidationResult { get; private set; }

        public bool IsValid
        {
            get
            {
                var fiscal = new OrderIsValidValidation();
                ValidationResult = fiscal.Valid(this);
                return ValidationResult.IsValid;
            }
        }

        public decimal Profit(decimal tax)
        {
             var amount = _orederAmount;
            //....
        }
    }

Potem w serwisie mapuje na to tabele Order za pomocą Nhibernate. Co można zarzucić takiemu podejściu?

Spotkałem się z opinią że tak nie wolno, że Presistance dla ORM powinno być oddzielnym bytem a Domain Model To taki adapter na te presistance.
No więc pytam.

somekind

2017-12-20 21:31

somekind2017-12-20 21:31

Moderator

Rejestracja:około 17 lat
Ostatnio:dzień
Lokalizacja:Wrocław

Jak dla mnie, to po prostu łamanie SRP, a problem może się pojawić wtedy, gdy na tej samej tabeli będzie opartych wiele operacji biznesowych, i taka klasa będzie miała masę metod, które mają sens tylko w określonym kontekście. Zrobi się z tego jakiś god object.
Dla prostych przypadków wolę już mieć model bez logiki i operujące na nim proceduralnie serwisy niż takich biznesowo-bazodanowych transwestytów w kodzie.

MrBean Bean

2017-12-20 21:40

MrBean Bean2017-12-20 21:40

Rejestracja:ponad 7 lat
Ostatnio:ponad 7 lat
Postów:117

Wydaje mi się, że przesadzasz, Gdzie te złamanie SRP, że niby Validacja? To twój ogólny problem do Domain Model i DDD. Czy po prostu implementacja ci się nie podoba ?

MrBean Bean

2017-12-20 21:41

MrBean Bean2017-12-20 21:41

Rejestracja:ponad 7 lat
Ostatnio:ponad 7 lat
Postów:117

i taka klasa będzie miała masę metod, które mają sens tylko w określonym kontekście. Zrobi się z tego jakiś god object.

A to zleży co dla ciebie jest usługą a co encją z kontekstu dziedziny...

Klojtex

2017-12-20 22:02

Klojtex2017-12-20 22:02

Rejestracja:ponad 7 lat
Ostatnio:4 miesiące
Postów:191

Sam siebie waliduje, sam wylicza swój podatek... Potem do tego dojdzie samodzielne wyliczanie obniżki ceny, później samodzielne wyliczenie okresów rozliczeniowych dla zamówień cyklicznych... I tak dalej.

O ile w prostych przypadkach od biedy możesz takie rozwiązanie popełnić, to niestety obawiam się, że bardzo szybko przypadek przestanie być prosty, a Ty zaczniesz rwać włosy z łydek, bo zrobi Ci się kaszana kodzie i to cudo zrobi się takim właśnie god-class.

SRP łamie toto choćby z powodu właśnie walidacji samego siebie. Choć pewno ktoś by mi za to stwierdzenie chętnie urwał kabel od internetu, to od walidacji są osobne mechanizmy, bo samosądy są niefajną sprawą, a i później w sumie nie do końca wiadomo jak to sprzężyć z realną logiką aplikacji żeby wyglądało po ludzku. Tak samo już wyliczanie podatku prawdopodobnie bym odseparował, bo w zależności od systemu prawnego sposób obliczania może się zupełnie różnić, niekoniecznie tylko wysokością ale jakąś większą logiką.(fakt, że o ile się orientuję to czysta fantazja aktualnie, ale jednak jest to jakiś, prymitywny, rodzaj logiki wkraczającej już w domenę na moje oko)

PS: Za dużo edycji... Teraz spojrzałem, że odseparowane to niby jest, choć znowu tworzysz tam sztywne powiązanie w ten sposób.
Nadal jednak podtrzymuję, że walidator lepiej wywołać zewnętrznie, bo wtedy możesz chociażby sterować scenariuszami walidacji w zależności od sytuacji przez, choćby, rzucenie argumentu.

MrBean Bean

2017-12-20 22:14

MrBean Bean2017-12-20 22:14

Rejestracja:ponad 7 lat
Ostatnio:ponad 7 lat
Postów:117

Nie ważne, mniejsza o szczegóły pytanie brzmiało jak mapować na Domain Model ...!!

Racja te obliczanie podatku tu nie pasuje, pisałem w nawiasie że przykład jest bez sensu...
Ale widzę tutaj metody np. submit() która zmienia status zamówienia na submit, AddToArchive(), GetTotalCost i tp. Validacja to zależy jeśli chcesz sprawdzić czy np user istnieje w bazie to jest validacja po stronie logiki biznesowej, przecież nie użyjesz do tego ViewModel.

edytowany 2x, ostatnio: MrBean Bean 2017-12-20 22:27

neves

2017-12-21 11:04

neves2017-12-21 11:04

Rejestracja:ponad 21 lat
Ostatnio:około 11 godzin
Lokalizacja:Kraków
Postów:1114

TL;DR
Jedyne co bym mógł zarzucić temu kawałkowi kodu nie znając szerszego kontekstu, to to że walidacja powinna być metodą a nie propertisem ;)

W obecnym podejściu niewiele można zarzucić temu fragmentu kodu, bo jest wyrwany z kontekstu i nie wiemy wszystkiego. No ale po kolei :

settery są "be" jeśli są publiczne, jeśli są prywatne lub chronione to nie naruszają enkapsulacji, no chyba że patrz punkt następny
czyli kwestia czy mieć oddzielny persistence model i domain model, czy jeden wspólny, jeśli nasze źródło danych jest modyfikowane tylko wyłącznie za pomocą naszego modelu, to jak najbardziej jeden model może być wystarczający, no chyba że tak nie jest, wtedy pojawia się punkt następny
czyli poprawność modelu do której wszystko się sprowadza(z tym ze model zawsze powinien być w poprawnym stanie prawie wszyscy się zgadzają w środowisku DDD)

Więc jeśli odtworzenie stanu modelu ze źródła danych nie może wprowadzić wspólnego modelu w stan niepoprawny to wszystko jest jak najbardziej okej (i setery i wspólny model):
-zawsze poprawne źródło danych -> ORM używa propertisów do odtworzenia stanu -> poprawny wspólny model
natomiast jeśli nasz scenariusz wygląda następująco (setetry są be, jak i wspólny model jest be)
-źródło danych które może być zmienione za plecami naszego modelu -> ORM używa propertisów do odtworzenia stanu -> dostajemy model w nie wiadomo w jakim stanie -> musimy walidować przy każdej próbie skorzystania z encji -> :(

Wiec pytanie czym jest walidacja i po co ona jest w tej encji?

jeśli do sprawdzenia czy niezmienniki danej encji są poprawne np (OrederAmount > 0), to oznacza że możemy mieć model w stanie niepoprawnym, a tego nie chcemy, model musi być zawsze poprawny
czy do sprawdzenia poprawności zamówienia z punktu biznesowego czyli np czy OrederAmount < od stanu magazynowego w chwili składania zamówienia, jest jak najbardziej okej

Odnośnie SRP i gdzie walidować, no to tutaj już nie ma konsensusu, jedni preferują encje, jedni serwisy biznesowe. Tak samo z tym liczeniem zysku, jeśli jest to coś bardzo prostego i niezmiennego uszło by zostawienie tego w encji, jakiś bardziej skomplikowany proces -> serwis.

**Podsumowując : model domenowy chcemy mieć zawsze w stanie poprawnym **

somekind 2017-12-21 11:47

Skoro model domenowy ma być zawsze poprawny, to IsValid powinno zawsze zwracać true, więc jaki w ogóle sens tego propertisa?

neves 2017-12-21 12:18

jeśli to ma być walidacja niezmienników to ona nie ma sensu

somekind 2017-12-21 12:37

A inna nie będzie się raczej nazywała IsValid.

neves 2017-12-21 12:53

prawda, ale mamy wyrwany fragment kodu, więc sobie możemy gdybać co autor miał na myśli :)

xxx_xx_x 2018-01-16 20:46

W przypadku liczenia zysku można pomyśleć o zastosowaniu Policy pattern (o ile nie wykracza to poza kontekst)

somekind

2017-12-21 11:28

somekind2017-12-21 11:28

Moderator

Rejestracja:około 17 lat
Ostatnio:dzień
Lokalizacja:Wrocław

MrBean Bean napisał(a):

Wydaje mi się, że przesadzasz, Gdzie te złamanie SRP, że niby Validacja?

SRP jest złamane bo Order ma dwa powody do zmiany - zarówno zmianę logiki biznesowej jak i przechowywanych danych.
Wsadzenie tam jeszcze walidacja to też naruszenie SRP, ale głównym problemem jest co innego - encje nie powinny się walidować po utworzeniu na polecenie zewnętrznych obiektów, po prostu nie powinno być w ogóle możliwości utworzenia niespójnej encji. A więc walidacja powinna być zrealizowana na etapie tworzenia obiektu, najczęściej w konstruktorze.

To twój ogólny problem do Domain Model i DDD.

Ale jakiego DDD? Tu nic takiego nawet nie widać.

neves napisał(a):

W obecnym podejściu niewiele można zarzucić temu fragmentu kodu, bo jest wyrwany z kontekstu i nie wiemy wszystkiego. No ale po kolei :

To zależy co to miało być, bo jeśli DDD, to w tym kontekście można zarzucić wszystko.

Więc jeśli odtworzenie stanu modelu ze źródła danych nie może wprowadzić wspólnego modelu w stan niepoprawny to wszystko jest jak najbardziej okej (i setery i wspólny model):

Ale później, przy pomocy publicznych setterów można już ten model wprowadzić w stan niespójny, co nie jest OK, dlatego przy DDD nie powinno ich być.

-zawsze poprawne źródło danych

Coś takiego w ogóle istnieje?

Odnośnie SRP i gdzie walidować, no to tutaj już nie ma konsensusu, jedni preferują encje, jedni serwisy biznesowe.

W serwisach domenowych powinno się walidować tylko to, czego encja sama nie może.

edytowany 1x, ostatnio: somekind 2017-12-21 11:57

neves 2017-12-21 12:16

zauważ że w przytoczonym fragmencie kodu nie ma publicznych seterów ;) i moja wypowiedź była właśnie w kontekście niepublicznych

somekind 2017-12-21 12:38

Ok, tu masz rację.

MrBean Bean

2017-12-22 00:55

MrBean Bean2017-12-22 00:55

Rejestracja:ponad 7 lat
Ostatnio:ponad 7 lat
Postów:117

neves napisał(a):

TL;DR
źródło danych które może być zmienione za plecami naszego modelu -> ORM używa propertisów do odtworzenia stanu -> dostajemy model w nie wiadomo w jakim stanie -> musimy walidować przy każdej próbie skorzystania z encji -> :(

Czyli chodzi ci o zbieżność w tym co zapisują różne źródła danych do sesji ORM? Mnie to wygląda jak źle napisany kod, to tak jak byś nie używał sesji tak jak powinieneś. Może podać jakiś przykład.?

edytowany 1x, ostatnio: MrBean Bean 2017-12-22 00:56

MrBean Bean

2017-12-22 01:06

MrBean Bean2017-12-22 01:06

Rejestracja:ponad 7 lat
Ostatnio:ponad 7 lat
Postów:117

somekind napisał(a):

MrBean Bean napisał(a):

Wydaje mi się, że przesadzasz, Gdzie te złamanie SRP, że niby Validacja?

Ale później, przy pomocy publicznych setterów można już ten model wprowadzić w stan niespójny, co nie jest OK, dlatego przy DDD nie powinno ich być.

Czytałem DDD Vrnona i Evana ale jakoś nikt nigdzie o tym nie wspomnieli raczej pachnie mi to Fowlerem i jego wywodami na temat Anemic Domain. Które i tak są trochę bezsensu bo to biznes deklaruje złożoność modelu a nie czyjeś zachcianki.

Jeśli masz taki z tym problem to przecież możesz zrobić sobie dwa konstruktory jeden pusty dla ORM i chronione propertysy i drugi constructor dla twojej dyspozycji wtedy nie będziesz mógł zmienić stanu po stworzeniu obiektu.

edytowany 3x, ostatnio: MrBean Bean 2017-12-22 02:58

somekind

2017-12-22 02:58

somekind2017-12-22 02:58

Moderator

Rejestracja:około 17 lat
Ostatnio:dzień
Lokalizacja:Wrocław

MrBean Bean napisał(a):

neves napisał(a):

TL;DR
źródło danych które może być zmienione za plecami naszego modelu -> ORM używa propertisów do odtworzenia stanu -> dostajemy model w nie wiadomo w jakim stanie -> musimy walidować przy każdej próbie skorzystania z encji -> :(

Czyli chodzi ci o zbieżność w tym co zapisują różne źródła danych do sesji ORM? Mnie to wygląda jak źle napisany kod, to tak jak byś nie używał sesji tak jak powinieneś. Może podać jakiś przykład.?

Nie każda baza należy do jednej aplikacji, i nie zawsze źródłem danych jest baza.

MrBean Bean napisał(a):

Jeśli masz taki z tym problem to przecież możesz zrobić sobie dwa konstruktory jeden pusty dla ORM i chronione propertysy i drugi constructor dla twojej dyspozycji w tedy nie będziesz mógł zmienić stanu po stworzeniu obiektu.

Ja nie mam z tym problemu, bo po prostu w skomplikowanych przypadkach mam rich domain model odseparowany od persistence modelu i nie łamię SRP, a w przypadku prostej logiki piszę logikę w transaction scriptach operujących bezpośrednio na persistence modelu. Ergo albo programuję proceduralnie albo obiektowo, ale za każdym razem świadomie i stosując się do zasad, a nie tworząc jakieś dziwne hybrydy, które prędzej czy później spowodują problemy.

MrBean Bean

2017-12-22 03:41

MrBean Bean2017-12-22 03:41

Rejestracja:ponad 7 lat
Ostatnio:ponad 7 lat
Postów:117

somekind napisał(a):

MrBean Bean napisał(a):

neves napisał(a):

TL;DR
źródło danych które może być zmienione za plecami naszego modelu -> ORM używa propertisów do odtworzenia stanu -> dostajemy model w nie wiadomo w jakim stanie -> musimy walidować przy każdej próbie skorzystania z encji -> :(

Czyli chodzi ci o zbieżność w tym co zapisują różne źródła danych do sesji ORM? Mnie to wygląda jak źle napisany kod, to tak jak byś nie używał sesji tak jak powinieneś. Może podać jakiś przykład.?

Nie każda baza należy do jednej aplikacji, i nie zawsze źródłem danych jest baza.

MrBean Bean napisał(a):

Jeśli masz taki z tym problem to przecież możesz zrobić sobie dwa konstruktory jeden pusty dla ORM i chronione propertysy i drugi constructor dla twojej dyspozycji w tedy nie będziesz mógł zmienić stanu po stworzeniu obiektu.

Ja nie mam z tym problemu, bo po prostu w skomplikowanych przypadkach mam rich domain model odseparowany od persistence modelu i nie łamię SRP, a w przypadku prostej logiki piszę logikę w transaction scriptach operujących bezpośrednio na persistence modelu. Ergo albo programuję proceduralnie albo obiektowo, ale za każdym razem świadomie i stosując się do zasad, a nie tworząc jakieś dziwne hybrydy, które prędzej czy później spowodują problemy.

Nie rozumiem dlaczego uważasz, że mapowanie z ORM na DM to złamanie SRP. Przecież DM ma odpowiadać jednemu obiektowi w bazie i zawierać jego niezbędne zachowania. Zachowania które są bardziej ogólne lub należą do warstwy widoku i tp. należy wywalić za płot. Jak to u ciebie wygląda najpierw mapujesz na presistance a potem gdzieś w serwisie mapujesz to na ten twój rich obiekt, czy jakiś adapter z niego robisz? Mnie to bardziej przypomina jakiś sadomasochizm. No chyba, że tak bardzo ci zależy na auto mapowaniu nie wiem.

Nie każda baza należy do jednej aplikacji, i nie zawsze źródłem danych jest baza.

To tak trudno zaimplementować Unit Of Work?
O co ci teraz z tym chodzi?

Ergo albo programuję proceduralnie albo obiektowo

Ty tak na serio z tym ?

edytowany 4x, ostatnio: MrBean Bean 2017-12-22 03:48

somekind

2017-12-22 11:41

somekind2017-12-22 11:41

Moderator

Rejestracja:około 17 lat
Ostatnio:dzień
Lokalizacja:Wrocław

MrBean Bean napisał(a):

Nie rozumiem dlaczego uważasz, że mapowanie z ORM na DM to złamanie SRP. Przecież DM ma odpowiadać jednemu obiektowi w bazie i zawierać jego niezbędne zachowania.

Kto tak powiedział? DM to model logiki i procesów, on nie ma nic wspólnego z żadną bazą danych ani ze szczegółami formatu zapisu danych. To jest inna warstwa abstrakcji.

Zachowania które są bardziej ogólne lub należą do warstwy widoku i tp. należy wywalić za płot.

Nie ma co wywalać, bo DM nawet nie ma nic wspólnego z widokiem, obiekty DM nigdy nie są przetwarzane na obiekty widoku.

Jak to u ciebie wygląda najpierw mapujesz na presistance a potem gdzieś w serwisie mapujesz to na ten twój rich obiekt, czy jakiś adapter z niego robisz?

Mapuję, robienie adaptera byłoby wyciekiem abstrakcji.

Mnie to bardziej przypomina jakiś sadomasochizm. No chyba, że tak bardzo ci zależy na auto mapowaniu nie wiem.

Nie zależy mi na mapowaniu, to smutna konieczność. Sadomasochizmem jest za to przerabianie logiki biznesowej i jej testów z powodu zmiany formatu zapisu w źródle danych.

To tak trudno zaimplementować Unit Of Work?

Lol. :D
I jak Unit of Work w mojej aplikacji zabezpieczy bazę danych przed wstawieniem niepoprawnych danych przez jakiś zewnętrzny system?

edytowany 1x, ostatnio: somekind 2017-12-22 11:43

MrBean Bean

2017-12-22 12:11

MrBean Bean2017-12-22 12:11

Rejestracja:ponad 7 lat
Ostatnio:ponad 7 lat
Postów:117

Kto tak powiedział? DM to model logiki i procesów, on nie ma nic wspólnego z żadną bazą danych ani ze szczegółami formatu zapisu danych. To jest inna warstwa abstrakcji.

Tak ale encja może mieć związek z bazą jeśli jej stan ma być utrwalany ale jednocześnie może być czym abstrakcyjny w stosunku do bazy itp.

Nie ma co wywalać, bo DM nawet nie ma nic wspólnego z widokiem, obiekty DM nigdy nie są przetwarzane na obiekty widoku.

No właśnie ;)

Mapuję, robienie adaptera byłoby wyciekiem abstrakcji.

To powiesz jak to ma wyglądać?

Nie zależy mi na mapowaniu, to smutna konieczność. Sadomasochizmem jest za to przerabianie logiki biznesowej i jej testów z powodu zmiany formatu zapisu w źródle danych.

Nie rozumiem o co ci chodzi...? Co format zapisu ma do mapowania ? To jaki formatu zapisu w źródle danych potrzebuje anemicznej encji. ?

Lol. :D
I jak Unit of Work w mojej aplikacji zabezpieczy bazę danych przed wstawieniem niepoprawnych danych przez jakiś zewnętrzny.

Tak z tym wyskoczyłeś, że niezrozumiałem co to ma do tematu. Myślałem że mówimy o jakiejś spójności z kilku źródeł danych.

edytowany 2x, ostatnio: MrBean Bean 2017-12-22 12:12

Shalom

2017-12-22 12:46

~~Shalom~~2017-12-22 12:46

Rejestracja:około 21 lat
Ostatnio:prawie 3 lata
Lokalizacja:Space: the final frontier
Postów:26433

Tak ale encja może mieć związek z bazą jeśli jej stan ma być utrwalany ale jednocześnie może być czym abstrakcyjny w stosunku do bazy itp.

Nie. Utrwalasz sobie jakieś dane co najwyżej. Może są związane z jedna encją a może z wieloma na raz? Ale jedno z drugim w kodzie nie powinno być nijak związane. Model logiki biznesowej powinien być zupełnie niezależny zarówno od widoku (patrz: mvc/mvp) jak i od innych dupereli jak persystencja. Zmiana frameworka do Prezentacji nie powinna nijak wpływać na logikę, tak samo jak zmiana sposobu przechowywania danych. Jak napiszesz grę w szachy to przecież logika gry nie ulega zmianie bo zamiast buttonów w okienku nagle masz szachownicę 3d w OpenGL. Analogicznie z punktu widzenia logiki nic się nie zmieniło jeśli statystyki przechowujesz teraz w bazie danych a nie w xmlu na dysku. Partia szachów nadal przebiega tak samo!

edytowany 1x, ostatnio: ~~Shalom~~ 2017-12-22 13:42

MrBean Bean

2017-12-22 12:56

MrBean Bean2017-12-22 12:56

Rejestracja:ponad 7 lat
Ostatnio:ponad 7 lat
Postów:117

Shalom napisał(a):

Tak ale encja może mieć związek z bazą jeśli jej stan ma być utrwalany ale jednocześnie może być czym abstrakcyjny w stosunku do bazy itp.

Nie. Utrwalasz sobie jakieś dane co najwyżej. Może są związane z jedna encją a może z wieloma na raz? Ale jedno z drugim w kodzie nie powinno być nijak związane. Model logiki biznesowej powinien być zupełnie niezależny zarówno od widoku (patrz: mvc/mvp) jak i od innych dupereli jak persystencja. Zmiana frameworka do Prezentacji nie powinna nijak wpływać na logikę, tak samo jak zmiana sposobu przechowywania danych. Jak napiszesz grę w szachy to przecież logika gry nie ulega zmianie bo zamiast buttonów w okienku nagle masz szachownicę 3d w OpenGL. Analogicznie z punktu widzenia logiki nic się nie zmieniło jeśli statystyki przechowujesz teraz w bazie danych a nie w xmlu na dysku. Partia szachód nadal przebiega tak samo!

Czyli w DM nie mogę utworzyć instancji obiektu persystencji a jedynie deklarować pola składowa przez konstruktor.??

A co jeśli klasa persystencji ma taką samą nazwę jak encja DM to jedynie namespace je identyfikuje czy używacie jakiejś konwencji dla nazwy?

Mapowanie z persystencji na DM musi być w serwisie ? czy, może w repo ?

somekind

2017-12-22 13:11

somekind2017-12-22 13:11

Moderator

Rejestracja:około 17 lat
Ostatnio:dzień
Lokalizacja:Wrocław

MrBean Bean napisał(a):

Czyli w DM nie mogę utworzyć instancji obiektu persystencji a jedynie deklarować pola składowa przez konstruktor.??

Tak.

A co jeśli klasa persystencji ma taką samą nazwę jak encja DM to jedynie namespace je identyfikuje czy używacie jakiejś konwencji dla nazwy?

Zazwyczaj sufiksem, np. PersistenceModel albo Dbo.

Mapowanie z persystencji na DM musi być w serwisie ? czy, może w repo ?

W serwisie być nie może, bo to będzie wyciek perzystencji do domeny. To repozytorium jest odpowiedzialne za dostarczenie encji.

MrBean Bean 2017-12-22 13:30

No nic fajnie, że mi znowu przemówiliście do rozsądku.

MrBean Bean

2017-12-22 13:15

MrBean Bean2017-12-22 13:15

Rejestracja:ponad 7 lat
Ostatnio:ponad 7 lat
Postów:117

No ale jeśli mam klasę typu POCO a szczegóły mapowania ORM mam wywalone do innej klasy to też nie mogę tego POCO używać w DM?. Na przykład: chciał bym te POCO przekazać jako parametr i w środku poustawiać co trzeba.

edytowany 3x, ostatnio: MrBean Bean 2017-12-22 13:19

MrBean Bean

2017-12-23 15:25

MrBean Bean2017-12-23 15:25

Rejestracja:ponad 7 lat
Ostatnio:ponad 7 lat
Postów:117

Jeśli oprócz określonej domeny chcę wyświetlić zwykły gird w widoku to w warstwie Aplikacji nad Domeną muszę zrobić serwis który będzie operował na ORM z Infrastruktury i mapował to na DTO...? Czy to rzeczywiście taka ergonomia?

edytowany 1x, ostatnio: MrBean Bean 2017-12-23 15:27

somekind

2017-12-29 04:15

somekind2017-12-29 04:15

Moderator

Rejestracja:około 17 lat
Ostatnio:dzień
Lokalizacja:Wrocław

MrBean Bean napisał(a):

No ale jeśli mam klasę typu POCO a szczegóły mapowania ORM mam wywalone do innej klasy to też nie mogę tego POCO używać w DM?. Na przykład: chciał bym te POCO przekazać jako parametr i w środku poustawiać co trzeba.

To raczej nie będzie zgodne z DDD, to będzie anemiczny model.

MrBean Bean napisał(a):

Jeśli oprócz określonej domeny chcę wyświetlić zwykły gird w widoku to w warstwie Aplikacji nad Domeną muszę zrobić serwis który będzie operował na ORM z Infrastruktury i mapował to na DTO...? Czy to rzeczywiście taka ergonomia?

Nie, to nie jest ergonomia. Moim zdaniem w ogóle mieszkanie logiki biznesowej i wyświetlania danych to zły pomysł.

Liczba odpowiedzi na stronę

Treść *

Treść

Podgląd

Kliknij, aby dodać treść...

Kliknij, aby dodać załącznik lub wklej ze schowka.

Instrukcja obsługi Markdown

Pomoc 1.18.8

Typografia

Edytor obsługuje składnie Markdown, w której pojedynczy akcent *kursywa* oraz _kursywa_ to pochylenie. Z kolei podwójny akcent **pogrubienie** oraz __pogrubienie__ to pogrubienie. Dodanie znaczników ~~strike~~ to przekreślenie.

Możesz dodać formatowanie komendami , , oraz .

Ponieważ dekoracja podkreślenia jest przeznaczona na linki, markdown nie zawiera specjalnej składni dla podkreślenia. Dlatego by dodać podkreślenie, użyj underline.

Komendy formatujące reagują na skróty klawiszowe: Ctrl+B, Ctrl+I, Ctrl+U oraz Ctrl+S.

Linki

By dodać link w edytorze użyj komendy lub użyj składni [title](link). URL umieszczony w linku lub nawet URL umieszczony bezpośrednio w tekście będzie aktywny i klikalny.

Jeżeli chcesz, możesz samodzielnie dodać link: <a href="link">title</a>.

Wewnętrzne odnośniki

Możesz umieścić odnośnik do wewnętrznej podstrony, używając następującej składni: [[Delphi/Kompendium]] lub [[Delphi/Kompendium|kliknij, aby przejść do kompendium]]. Odnośniki mogą prowadzić do Forum 4programmers.net lub np. do Kompendium.

Wspomnienia użytkowników

By wspomnieć użytkownika forum, wpisz w formularzu znak @. Zobaczysz okienko samouzupełniające nazwy użytkowników. Samouzupełnienie dobierze odpowiedni format wspomnienia, zależnie od tego czy w nazwie użytkownika znajduje się spacja.

Znaczniki HTML

Dozwolone jest używanie niektórych znaczników HTML: <a>, , , <kbd>, <del>, , <dfn>, <pre>, <blockquote>, <hr/>, ,  oraz <img/>.

Skróty klawiszowe

Dodaj kombinację klawiszy komendą notacji klawiszy lub skrótem klawiszowym Alt+K.

Reprezentuj kombinacje klawiszowe używając taga <kbd>. Oddziel od siebie klawisze znakiem plus, np <kbd>Alt+Tab</kbd>.

Indeks górny oraz dolny

Przykład: wpisując H2O i m2 otrzymasz: H₂O i m².

Składnia Tex

By precyzyjnie wyrazić działanie matematyczne, użyj składni Tex.

<tex>arcctg(x) = argtan(\frac{1}{x}) = arcsin(\frac{1}{\sqrt{1+x^2}})</tex>

Kod źródłowy

Krótkie fragmenty kodu

Wszelkie jednolinijkowe instrukcje języka programowania powinny być zawarte pomiędzy obróconymi apostrofami: `kod instrukcji` lub ``console.log(`string`);``.

Kod wielolinijkowy

Dodaj fragment kodu komendą . Fragmenty kodu zajmujące całą lub więcej linijek powinny być umieszczone w wielolinijkowym fragmencie kodu. Znaczniki ``` lub ~~~ umożliwiają kolorowanie różnych języków programowania. Możemy nadać nazwę języka programowania używając auto-uzupełnienia, kod został pokolorowany używając konkretnych ustawień kolorowania składni:

```javascript document.write('Hello World'); ```

Możesz zaznaczyć również już wklejony kod w edytorze, i użyć komendy by zamienić go w kod. Użyj kombinacji Ctrl+`, by dodać fragment kodu bez oznaczników języka.

Tabelki

Dodaj przykładową tabelkę używając komendy . Przykładowa tabelka składa się z dwóch kolumn, nagłówka i jednego wiersza.

Wygeneruj tabelkę na podstawie szablonu. Oddziel komórki separatorem ; lub |, a następnie zaznacz szablonu.

nazwisko;dziedzina;odkrycie
Pitagoras;mathematics;Pythagorean Theorem
Albert Einstein;physics;General Relativity
Marie Curie, Pierre Curie;chemistry;Radium, Polonium

Użyj komendy by zamienić zaznaczony szablon na tabelkę Markdown.

Lista uporządkowana i nieuporządkowana

Możliwe jest tworzenie listy numerowanych oraz wypunktowanych. Wystarczy, że pierwszym znakiem linii będzie * lub - dla listy nieuporządkowanej oraz 1. dla listy uporządkowanej.

Użyj komendy by dodać listę uporządkowaną.

1. Lista numerowana
2. Lista numerowana

Użyj komendy by dodać listę nieuporządkowaną.

* Lista wypunktowana
* Lista wypunktowana
** Lista wypunktowana (drugi poziom)

Składnia Markdown

Edytor obsługuje składnię Markdown, która składa się ze znaków specjalnych. Dostępne komendy, jak formatowanie , dodanie tabelki lub fragmentu kodu są w pewnym sensie świadome otaczającej jej składni, i postarają się unikać uszkodzenia jej.

Dla przykładu, używając tylko dostępnych komend, nie możemy dodać formatowania pogrubienia do kodu wielolinijkowego, albo dodać listy do tabelki - mogłoby to doprowadzić do uszkodzenia składni.

W pewnych odosobnionych przypadkach brak nowej linii przed elementami markdown również mógłby uszkodzić składnie, dlatego edytor dodaje brakujące nowe linie. Dla przykładu, dodanie formatowania pochylenia zaraz po tabelce, mogłoby zostać błędne zinterpretowane, więc edytor doda oddzielającą nową linię pomiędzy tabelką, a pochyleniem.

Skróty klawiszowe

Skróty formatujące, kiedy w edytorze znajduje się pojedynczy kursor, wstawiają sformatowany tekst przykładowy. Jeśli w edytorze znajduje się zaznaczenie (słowo, linijka, paragraf), wtedy zaznaczenie zostaje sformatowane.

Ctrl+B - dodaj pogrubienie lub pogrub zaznaczenie
Ctrl+I - dodaj pochylenie lub pochyl zaznaczenie
Ctrl+U - dodaj podkreślenie lub podkreśl zaznaczenie
Ctrl+S - dodaj przekreślenie lub przekreśl zaznaczenie

Notacja Klawiszy

Alt+K - dodaj notację klawiszy

Fragment kodu bez oznacznika

Alt+C - dodaj pusty fragment kodu

Skróty operujące na kodzie i linijkach:

Alt+L - zaznaczenie całej linii
Alt+, Alt+ - przeniesienie linijki w której znajduje się kursor w górę/dół.
Tab/⌘+] - dodaj wcięcie (wcięcie w prawo)
Shit+Tab/⌘+[ - usunięcie wcięcia (wycięcie w lewo)

Dodawanie postów:

Ctrl+Enter - dodaj post
⌘+Enter - dodaj post (MacOS)

Mapowanie na Domain Model

MrBean Bean napisał(a):

neves napisał(a):

neves napisał(a):

somekind napisał(a):

MrBean Bean napisał(a):

MrBean Bean napisał(a):

neves napisał(a):

MrBean Bean napisał(a):

somekind napisał(a):

MrBean Bean napisał(a):

neves napisał(a):

MrBean Bean napisał(a):

MrBean Bean napisał(a):

Shalom

Shalom napisał(a):

MrBean Bean napisał(a):

MrBean Bean napisał(a):

MrBean Bean napisał(a):

Smileys & People

Animals & Nature

Food & Drink

Travel & Places

Activities

Objects

Symbols

Typografia

Linki

Wewnętrzne odnośniki

Wspomnienia użytkowników

Znaczniki HTML

Skróty klawiszowe

Indeks górny oraz dolny

Składnia Tex

Kod źródłowy

Krótkie fragmenty kodu

Kod wielolinijkowy

Tabelki

Lista uporządkowana i nieuporządkowana

Składnia Markdown

Skróty klawiszowe