Joel,
> 1) When do you ever need multiple datacontexts?
I don't think you'd ever "need" to, but I've used a pattern with
multiple DataContexts. It's a little wacky, but worked pretty well.
I basically have two DataContexts, a shared application scope
DataContext and another one in a tapestry visit object. The shared
DataContext contained reference objects like countries and states (or
objects that seem like extra baggage in a session scope DataContext).
So, for example, in a user registration page, I'd use the shared
DataContext to build country and state popups. In the form's listener,
I'd capture the shared country and state selection and copy into the
user's visit DataContext, set relationship, and commit changes.
I'm not sure how much more efficient this approach is, it's just
something I tried when noticing that the was a lot of mostly static
reference data being stored in the session's DataContext.
Cheers,
e.
On 12/5/05, Joel Trunick <joel.trunic..ebifysolutions.com> wrote:
>
> I've been putting static methods on my domain objects to perform things
> like queries (for that object), and even simple methods load an instance
> by ID (returning an instance of the proper type). I find this
> organization very straightforward to use from a client perspective.
>
> However, to do this I rely on the DataContext bound to the thread a lot,
> and I'm wondering if this is architecturally flawed.
>
> I've already recognized that some (not all) of the queries belong on the
> client-side (tapestry pages), according to the DDD book, so I'm looking
> at getting rid of all these thread dependent methods.
>
> The question is then:
> 1) When do you ever need multiple datacontexts? (right now from web app)
> 2) Is the thread bound context a limitation?
>
> J
>
>
This archive was generated by hypermail 2.0.0 : Mon Dec 05 2005 - 13:35:02 EST