🚀 go-pugleaf

> Rodzic r = new Rodzic();
> rodzicRepository.Add(r);
>
> r.AddDziecko(new Dziecko());
> // co z repository? Jak to zawołać? Kto?

np.:
Dziecko d = new Dziecko();
r.AddDziecko( d );
dzieckoRepository.Add( d );

Wiktor Zychla

 

Dnia 25-02-2010 o 10:10:03 Wiktor Zychla <wzychla@nospam.com> napisał(a):

>> Rodzic r = new Rodzic();
>> rodzicRepository.Add(r);
>>
>> r.AddDziecko(new Dziecko());
>> // co z repository? Jak to zawołać? Kto?
>
> np.:
> Dziecko d = new Dziecko();
> r.AddDziecko( d );
> dzieckoRepository.Add( d );
>

Tylko, że Rodzic i Dziecko są jednym agregatem, a jego korzeniem jest  
Rodzic. W związku z tym powinienem mieć jedno repozytorium.
W twoim przykładzie trochę bez sensu jest dodawanie dziecka do rodzica,  
skoro i tak muszę dodać Dziecko do repozytorium.

Wydaje mi się, że musiałbym zrobić jakieś swoje śledzenie zmian w całych  
grafach obiektów i na podstawie zauważonych zmian
dodawać/update'ować/usuwać. Chyba trochę za dużo roboty, aby robić to  
samemu.

W dniu 2010-02-25 00:05, 3P pisze:
> Cześć.
>
> Chciałbym sobie zaimplementować Repository pattern.
>
> Jednak wszystkie przykłady w sieci sa dla prostych obiektów.
>
> Np.
>
> Obiekt o = new Obiekt();
> repository.Add/Remove/Update(o);
>
>
> Ale jak to powinno wygladać, gdy mamy relację Rodzic-Dziecko pomiędzy
> obiektami?
>
> class Rodzic
> {
> public List<Dziecko> Dzieci;
> }
>
> Rodzic r = new Rodzic();
> rodzicRepository.Add(r);
>
> r.AddDziecko(new Dziecko());
> // co z repository? Jak to zawołać? Kto?
>
>
> Czy implementował ktoś ten wzorzec, lub widzał jakieś bardziej złożone
> przykłady niż mój pierwszy?

Nie znam się na wzorcach, ale ja tu widzę klasę Node po której 
dziedziczą Rodzic i Dziecko lub ostatecznie w tym przypadku może być 
kompozycja.

artur

> Rodzic. W związku z tym powinienem mieć jedno repozytorium.

nie znam żadnych konkretnych implementacji, więc trudno powiedzieć czy tak 
powinno być czy nie.
z opisu samego wzorca nie wynika wiele, w szczególności nie wiadomo czy 
powinno być repozytorium per hierarchia czy per kategoria danych.

> W twoim przykładzie trochę bez sensu jest dodawanie dziecka do rodzica, 
> skoro i tak muszę dodać Dziecko do repozytorium.

w moim rozumieniu repozytorium jako interfejsu dla jednego typu danych to 
jakoś tak musiało by być.

> Wydaje mi się, że musiałbym zrobić jakieś swoje śledzenie zmian w całych 
> grafach obiektów i na podstawie zauważonych zmian
> dodawać/update'ować/usuwać. Chyba trochę za dużo roboty, aby robić to 
> samemu.

chyba że opakujesz jakąś technologię która robi to sama. wtedy tylko 
pytanie - po co Ci repozytorium.

tak nawiasem mówiąc - to pytanie jest i tak zasadne.

pozdrawiam
Wiktor Zychla 

> chyba że opakujesz jakąś technologię która robi to sama. wtedy tylko  
> pytanie - po co Ci repozytorium.
>
> tak nawiasem mówiąc - to pytanie jest i tak zasadne.
>
> pozdrawiam
> Wiktor Zychla

Czymś muszę zawsze opakować. Staram się poznać i stosować Domain Driven  
Development, a repozytoria zapewniają dostęp do obiektów w DDD.

What exactly was the intent of the repository pattern in the first place?  
Looking back to [DDD, Evans] one will see that it is to represent a series  
of objects as if they were a collection in memory so that the domain can  
be freed of persistence concerns. In other words the goal is to put  
collection semantics on the objects in persistence.

The key here is that as a rule there should be no persistence logic within  
the domain. This allows the domain to be more easily tested, tested  
independently of persistence and moved easily from a persistence mechanism  
(this is more important as a long term maintainability goal as opposed to  
“we want to use XML files now”).

Simply put the contract of the Repository represents the contract of the  
domain to the persistence mechanism for the aggregate root that the  
repository supports. The realization that the Repository is less of an  
object and more of a contract to infrastructure is both a subtle and  
important one.