Re: Repository Questions

[MarcoP]

I've re-read the repositories section a few time and I have a few
questions. "out-of-bounds comunication are needed for business rule
such as "a customer can not be deleted" or "you can search bonds by
rating". can you explain how the repository helps with this? Also,
does the repository have the responsiblity for loading the entire
aggregate or does that happen in above layers (application for
example)?

If an entity needs a reference to an root in another aggregate, how do
you ensure the aggregate gets fully loaded? Does the magic of Epic use
a proxy that lazy loads by calling the roots associated repository?

[Giacomo Tesio]

WOW ! ! ! Feedbacks! You are really REALLY wellcome! :-D

In that chapter I talk about the limits of two mainstream approaches:

- generic repositories that, by exposing a general purpose interface require out-of-bound comunications about which methods are safe to be called (for example Delete(T)).

- custom repositories that expose explicit strongly typed query methods bound to the needs of the clients

We choosed IQueryable<T> as it allows for strongly typed general purpose queries but as for creation and deletion the Epic's way is described later:

no repository should provide such methods, as they are always owned by a bounded role. Indeed there is always a user responsible for the creation or the elimination of an entity.

As for lazy loading, no, you never need it.

The key here is in shared identifiers. The ancestors of Epic.Poem (the epic's component that will handle the presentation layer) proved that with a good presentation framework you can avoid lazy loading at all, what you need from different repositories with Linq.

The challenging point, however, is to build queryproviders that handle such requirements.

Indeed we have a few high skilled developers that are experts on the topic (as for me, I was one of the developers of the DbLinq project that produced the Mono's Linq provider).

In the last year we adopted Relinq, but while very good per se, I think that the Epic's approach would meet better the needs of the market we target (and would integrate better with the rest of the framework, particularly with Epic.Server).

Please let us know more questions and point. If something looks obscure, let us know!

Giacomo 

PS: where are you from? As your name is Marco I was wondering if you are from Italy...

[MarcoP]

When I was referring to lazy loading, i was thinking when you need to
send a command to a domain object and when that aggregate is pulled
from the repository its fully loaded. is my thinking correct? The
project sounds very exciting!

I am from the US but my wife is italian and we actually visited
Costinano (where here roots stem from) last year!

On Sep 1, 9:56 am, Giacomo Tesio <giac...@tesio.it> wrote:
> WOW ! ! ! Feedbacks! You are really REALLY wellcome! :-D
>
> In that chapter I talk about the limits of two mainstream approaches:
> - generic repositories that, by exposing a general purpose interface require
> out-of-bound comunications about which methods are safe to be called (for
> example Delete(T)).
> - custom repositories that expose explicit strongly typed query methods
> bound to the needs of the clients
>
> We choosed IQueryable<T> as it allows for strongly typed general purpose
> queries but as for creation and deletion the Epic's way is described later:
>

> no repository should provide *such methods*, as they *are always owned by a
>
> > bounded role*. Indeed there is always a user responsible for the creation

> > or the elimination of an entity.
>
> As for lazy loading, no, you never need it.
>
> The key here is in shared

> identifiers<http://epic.tesio.it/doc/shared_identifiers.html>.

[Giacomo Tesio]

When you query a repository and get an instance of a entity (all aggregate roots are entities) you have the full entity, no more loading is needed.

This is efficient if and only if you designed the context boundaries correctly.

Bigger contexts lead to heavy entities.

It's not by chance that the chapter about bounded roles is early in the manual (long before that in the Evans' book).

The project *is* exiting... but it's a long journey that requires constancy and still a lot of really hard work.

Giacomo

[MarcoP]

got it, it's making more and more sense. so does epic have seperate
models for read (displaying on web page for example) and writes
(creating an order) ? I've been trying to think how one model could
serve both purposes but i can forsee the associations getting out of
control. for example, order and product aggregates. if we need to show
the purchased product on the screen, the order aggregate only contains
the product id, not the full aggregate, thus not having the product
name. does that make sense?