Dapper ORM w DDD

0

Witam,
mozna wykonac operacje AddAsync bazując na modelu typu DDD (czyli propierties z protected setterami, są okreslane w konstruktorze modelu) przy wykorzystaniu Dappera?

Klasa wygląda tak

public class abc
{
Public Guid Id {get; protected set;}
Public string Name {get; protected set;}
...

Public abc(string name)
{
Id=Guid.new();
SetName(name);
...
}

Protected void SetName(string name)
{
Name=name;
}
}
```c
3

A czy nie powinieneś iść bardziej w kierunku model bazodanowy oraz model domenowy niż łączyć je i walczyć z modyfikatorami dostęp, OOP i może nawet logiką domenową?

5
Piotr Kombinski napisał(a):

mozna wykonac operacje AddAsync bazując na modelu typu DDD (czyli propierties z protected setterami

Jeśli wg Ciebie DDD polega na tym, że model ma protected settery, to możesz równie dobrze zrobić je publiczne i pozbyć się swojego problemu.

3

Ja wiem, że cały koncept ddd nie polega wyłącznie od sposobu zarządzania propiertisami, a o sposobie budowy logiki biznesowej aplikacji itp. Tylko panie weź na poprawkę, że chciałbym się tego nauczyć.

3

Nie wiem czy jest sens odpisywać komuś, kto próbuje robić debili z użytkowników forum, ale niech będzie.

Uniwersalne i najprostsze rozwiązanie jest jedno - oddzielenie modelu domenowego od modelu składowania danych.
Można mieć jeden model, tylko jeśli mamy ORM, który to ogarnia. Ale ORM raczej będzie wymagał normalnego konstruktora, a nie aberracji.

protected set i metoda do ustawiania wartości pola, to ani C# ani DDD, to czysty absurd i nonsens. Co daje ten protected, skoro i tak wszystko może być ustawione publiczną metodą?

2

Nie jest wystarczająco fancy, brakuje jeszcze protected internal

A tak na serio to co chcesz osiągnąć?

Bo póki co masz:

  • Settera rodem z Javy
  • Active Record
  • Infrastrukturę w wartstwie domeny
  • Użycie dappera z modelem domeny jest równie przyjemne co podcieranie się papierem ściernym 150

Może ze złych źródeł korzystasz do nauki, albo DDD jest ci potrzebne jak 3 koło w rowerze, bo póki co to DDD to 3 razy du**

2

Koledzy troche polecieli z krytyka, aczkolwiek krytyka sama w sobie w tym przypadku jest sluszna. Dapper pozwala ladowac dane ktore nastepnie sa wstrzykiwane przez konstruktor- i to tyle jesli chodzi o cokolwiek co na upartego mozna by powiazac z wymaganiami zwiazanymi z DDD bo mozna tworzyc instancje agregatow ktore maja prywatne settery (lub wcale ich nie maja). Problem w tym ze agregaty to zazwyczaj klastry obiektow, wiec sila rzeczy nie da sie tego zaladowac z jednej tabeli- stad tez do zapisywania i ladowania agregatow lepiej nadaja sie bazy dokumentowe (NoSQL). W przeciwnym razie najbardziej rozsadnym rozwiazaniem jest wspomniane juz oddzielenie modelow domenowych od modeli perzystencji.

To co zaprezentowales w przykladowym kodzie jest zwyczajnie bledne, a i nie nie rozumiem co masz na mysli pytajac czy mozna wykonac operacje AddAsync bazując na modelu typu DDD.

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