Wpis z mikrobloga

@newbie_235235: Załóżmy jak masz coś takiego jak w DDD Value Object to mapowanie go mapperem jest moze i zle...bo value object sam sie potrafi zawalidowac np.

class PhoneNumber {

PhoneNumber(String number) {
validate(number)

}
}

Walidacje mozna zrobis w JSR 303 na DTO jakas adnotacja ale jak adnotacji ktos nie zrobic to mapper moze przepchac wszystko...

Co entity to trzeba ja zmapowac z DTO do Encji ale czy zawsze Mapper jest
Co z enkapsulacją? Używając mapera, muszę dodać wszystkie gettery/settery.


@newbie_235235: i w jaki sposób wpływa to na enkapsulację? :D

Możesz sobie w w DTO potworzyć metody np: EntityDto fromEntity(Entity entity) i vice versa.
Swoją drogą, posty tutaj pokazują, co się dzieje, gdy Wujek Bob, Sobótka, czy inny teoretyk programowania wejdzie za mocno - ludzie koncentrują się nad rozkminianiem, czy dana implementacja nie łamie jednego z 35234235 pryncypiów "dobrego" programowania powstałego na przestrzeni ostatnich 10 lat, zamiast po prostu napisać coś, co działa.
imho jedyną słuszną drogą jest wzięcia ID z DTO i poproszenie hibernate o zwrotkę Encji, w przeciwnym wypadku:
- w jaki stanie będzie encja dla hibernate, detached?
- co jeżeli DTO ma stan przestarzały względem bazy?
- musisz zapewnić 1:1 między DTO a Encją (a zazwyczaj jedna encja potrafi "złożyć się" do kilku różnych DTO, w zależności od tego co wystawiasz z domeny), bo skądś te wszystkie pola muszą się znaleźć

Nie