Chyba rozumiem o czym piszecie, ale może ja napiszę trochę prościej. Nie do końca wiem jak wykonać aktualizacje danych w bazie mając przesłane DTO do Controllera. Tym DTO jest np.: Order, OrderItems i jakieś inne właściwości, które reprezentują Order na UI. Chyba z uwagi na DDD powinno to przejść przez obiekt domenowy zachowując jego logikę. Jednak z punktu widzenia biznesowego zmiana właściwości np.: Uwagi nie ma chyba znaczenia. Mowiąc krótko w jaki sposób zaaktualizować bazę mając przesłane DTO.
0
0
Mógłbyś dokładnie wyjaśnić co masz na myśli?
O to, że DTO zwykle jest tworzone na potrzeby klienta graficznego, czy komunikacji pomiędzy procesami. Ty powinieneś jedynie przekazać prymitywy z ViewModelu do metody serwisu.
0
Krzywy Rycerz napisał(a):
Mógłbyś dokładnie wyjaśnić co masz na myśli?
O to, że DTO zwykle jest tworzone na potrzeby klienta graficznego, czy komunikacji pomiędzy procesami. Ty powinieneś jedynie przekazać prymitywy z ViewModelu do metody serwisu.
Prymitywy czyli co dokładnie? DTO tutaj nazywasz ViewModelem? A w jaki sposób zaaktualizować właściwości domeny które nie przeiwdują zmiany wartości z punktu widzenia biznesowego (czyli zwykły CRUD, zmiana chociażby polwa Uwagi)
0
Prymitywy czyli long, guid, int, string, decimal itp.
Z web UI przekazujesz do kontrolera ViewModel, który ma jakieś prymitywy (string, int, long) a metody serwisu czy AR pracują na prymitywach.
Co to znaczy: "nie przewidują zmiany wartości z punktu widzenia biznesowego"? To czy pole Uwagi to część CRUDa to zależy od modelu. Np. u mnie wpisanie Uwag do zamówienia czy pozycji zamówienia trochę zmieniało w obsłudze zamówienia. Bo to zwykle białkowiec musi przeczytać i może zaakceptować albo podjąć jakieś działania a bez uwag idzie sobie automatem do realizacji (odpala jakieś zlecenia produkcyjne czy magazynowe). Więc nie jest to operacja CRUD.
Z drugiej strony pisałem niedawno aplikacje do laboratorium i tam jest tylko zapisanie danych do bazy plus jakieś proste wyliczenia i wydruki. I tam jest tylko generyczne repo. Niczego więcej nie trzeba.
Co do zmiany pojedynczych właściwości to trzeba przeanalizować czy np. jest dopuszczalna w pozycji zamówienia zmiana tylko produktu. Bo może dla innego produktu ilość w pozycji zamówienia ma inną jednostkę i zamienisz wiadra, które są w sztukach na mąkę w kilogramach. No i wtedy jakieś obliczenia rabatów, sprawdzenie dostępności itp. Więc AR może mieć metodę do zmiany ilości dla pozycji zamówienia a niekoniecznie dla zmiany produktu. Albo do zmiany produktu tylko razem z ilością i jakimiś opcjami.
DTO vs. ViewModel
https://4programmers.net/Forum/C_i_.NET/289539-roznice_miedzy_dto_a_viewmodel_we_wzorcu_mvc
0
jacek.placek napisał(a):
Prymitywy czyli long, guid, int, string, decimal itp.
Z web UI przekazujesz do kontrolera ViewModel, który ma jakieś prymitywy (string, int, long) a metody serwisu czy AR pracują na prymitywach.Co to znaczy: "nie przewidują zmiany wartości z punktu widzenia biznesowego"? To czy pole Uwagi to część CRUDa to zależy od modelu. Np. u mnie wpisanie Uwag do zamówienia czy pozycji zamówienia trochę zmieniało w obsłudze zamówienia. Bo to zwykle białkowiec musi przeczytać i może zaakceptować albo podjąć jakieś działania a bez uwag idzie sobie automatem do realizacji (odpala jakieś zlecenia produkcyjne czy magazynowe). Więc nie jest to operacja CRUD.
Z drugiej strony pisałem niedawno aplikacje do laboratorium i tam jest tylko zapisanie danych do bazy plus jakieś proste wyliczenia i wydruki. I tam jest tylko generyczne repo. Niczego więcej nie trzeba.Co do zmiany pojedynczych właściwości to trzeba przeanalizować czy np. jest dopuszczalna w pozycji zamówienia zmiana tylko produktu. Bo może dla innego produktu ilość w pozycji zamówienia ma inną jednostkę i zamienisz wiadra, które są w sztukach na mąkę w kilogramach. No i wtedy jakieś obliczenia rabatów, sprawdzenie dostępności itp. Więc AR może mieć metodę do zmiany ilości dla pozycji zamówienia a niekoniecznie dla zmiany produktu. Albo do zmiany produktu tylko razem z ilością i jakimiś opcjami.
DTO vs. ViewModel
Różnice między DTO, a ViewModel we wzorcu MVC
Dzięki za odpowiedź. Nie układa mi się w całość jeszcze jedna rzecz. Użytkownik wchodząc w edycję takiego zamówienia może zmienia Uwagi, a może nic nie zmienia - po kliknięciu przycisku "Zapisz" do API przecież leci cały DTO z UI - czyli całe zamówienie w tym wypadku. W jaki sposób rozróżnić czy mamy wykonać logikę domenową czy zrobić zwyklego CRUD-a np.: dla poł które nie maja wypływu na logikę biznesowa? Czy może w takim wypadku realizować CRUD-a dla tych elementów;/? Nie wiem czy wiesz o co mi chodzi - ale krótko mówiąc o to co się ma dziać z takim wysłanym zamówieniem do API, gdzie nie wiemy jakich zmian dokonał użytkownik. Zmiana np.: ilości na zamówieniu może wiązać się przykładowo z tym, że zmieniany jest stan magazynowy czy cokolwiek innego więc logika biznesowa powinna zostać wykonana.
0
W jaki sposób rozróżnić czy mamy wykonać logikę domenową czy zrobić zwyklego CRUD-a np..: dla poł które nie maja wypływu na logikę biznesowa?
Wywołujesz dwa Serwisy w Kontrolerze. Pisałem o tym na top trzeciej strony.
Z drugiej strony pisałem niedawno aplikacje do laboratorium i tam jest tylko zapisanie danych do bazy plus jakieś proste wyliczenia i wydruki. I tam jest tylko generyczne repo. Niczego więcej nie trzeba.
To nie jest Repo :)
0
Nie widzę od ciebie żadnego wpisu w tym wątku - na żadnej ze stron.
Patrz na Zimny Młot
Forum losuje mi nick, nie czuje potrzeby budowania własnego wizerunku w internecie....
0
Biały Kret napisał(a):
Nie widzę od ciebie żadnego wpisu w tym wątku - na żadnej ze stron.
Patrz na Zimny Młot
Forum losuje mi nick, nie czuje potrzeby budowania własnego wizerunku w internecie....
OK:)
Rozumiem, że chodzi ci o to, że przesyłając takie zamówienie do Controllera wywołuję logikę domenową czyli jakiś DomainServiceA, a następnie jakiś AppServiceA "uzupełniający" pola, które nie mają wpływu na logikę?
0
jacek.placek napisał(a):
Prymitywy czyli long, guid, int, string, decimal itp.
Z web UI przekazujesz do kontrolera ViewModel, który ma jakieś prymitywy (string, int, long) a metody serwisu czy AR pracują na prymitywach.
Tylko po co sobie tak życie utrudniać i tracić czas na dekompozycję gotowego obiektu? Co z zasadami czystego kodu i ideą programowania obiektowego w ogólności?
0
@somekind: Ja nie zajmuję stanowiska w tej sprawie tylko dopowiadam wyjaśnienie do postu Zimnego Młota i w kontekście jego wypowiedzi. Chociaż zdarzało mi się coś takiego pisać w przypadku jakichś bardzo prostych operacji. Mam wrażenie, ze javowe przykłady DDD coś takiego pokazują.
0
Tylko po co sobie tak życie utrudniać i tracić czas na dekompozycję gotowego obiektu? Co z zasadami czystego kodu i ideą programowania obiektowego w ogólności?
No tak, oczywiście możesz mieć np. drugą warstwę, która zawiera "kontrakt".
Jeśli chodzi o DDD to dekompozycję wykonuje aby uniknąć tego:
ProductService.ChangePrice(productId, newPrice)
//Zamiast
ProductService.ChangePrice(Model); <--- WTF is model?
W DDD takie zjawisko nazywane jest amnezją. Oczywicie nie jest to złota zasada, jeśli użycie obiektu zbiorczego w kontekście DDD ma sens to OKey.
Zrobienie całego projektu w paradygmacie obiektowy od dechy do dechy często nie ma sensu. Dlatego jestem za tym aby generyczne funkcjonalności wprowadzać z wykorzystaniem również paradygmatu dynamicznego. Zrestą większość CQRS'ów to i tak bardziej przypomina programowanie proceduralny czy funkcyjne.
0
Elementów dynamicznych jezyka, aspektów, interceptorów, nie paradygmatu dynamicznego. ;)
0
moneusz napisał(a):
Biały Kret napisał(a):
Nie widzę od ciebie żadnego wpisu w tym wątku - na żadnej ze stron.
Patrz na Zimny Młot
Forum losuje mi nick, nie czuje potrzeby budowania własnego wizerunku w internecie....
OK:)
Rozumiem, że chodzi ci o to, że przesyłając takie zamówienie do Controllera wywołuję logikę domenową czyli jakiś DomainServiceA, a następnie jakiś AppServiceA "uzupełniający" pola, które nie mają wpływu na logikę?
Mogę liczyc na jakieś opinie w tym temacie?
0
Tylko po co sobie tak życie utrudniać i tracić czas na dekompozycję gotowego obiektu? Co z zasadami czystego kodu i ideą programowania obiektowego w ogólności?
No, chyba że chcesz pisać komendy do każdej metody.
W kontekście DDD nie wyobrażam sobie operowania na ViewModelach jako input do serwisów.
0
Biały Kret napisał(a):
Jeśli chodzi o DDD to dekompozycję wykonuje aby uniknąć tego:
ProductService.ChangePrice(productId, newPrice) //Zamiast ProductService.ChangePrice(Model); <--- WTF is model?
No właśnie, WTF? Czemu ktoś tak nazwał zmienną?
I to w ogóle nie za bardzo jest przykład na DDD, ale niech będzie. W przypadku małej liczby parametrów to może sens, ale jak parametrów jest dużo, to nie ma powodu, aby rezygnować z przesłania bardziej złożonej struktury danych - nie twierdzę, że to musi być viewmodel w całości. Tylko zmienne trzeba nazywać rozsądnie.
Zrobienie całego projektu w paradygmacie obiektowy od dechy do dechy często nie ma sensu. Dlatego jestem za tym aby generyczne funkcjonalności wprowadzać z wykorzystaniem również paradygmatu dynamicznego. Zrestą większość CQRS'ów to i tak bardziej przypomina programowanie proceduralny czy funkcyjne.
Nawet w proceduralnym czy fukcyjnym trzyma się grupy powiązanych ze sobą wartości razem.