Re: How it all fits together

Re: Database transaction of the Repository?

I just walked through the code in SmartCA. What confuse me is the 
IRepository more like a IDataMapper, which is sit in the 
Infrastructure/Persistence layer & without the Matching(ICriteria 
criteria) method. Besides, its IEntity & IUnitOfWork also in the 
Infrastructure layer. It doesn't have clean separation between the 
domain and infrastructure. 
Is this the only pragmatic way of coding? Or I have missed something? 
Thank you.

--- In domaindrivendesign <at> yahoogroups.com, "Dicky Arinal" 
<dicky.arinal@...> wrote:
>
> On Wed, May 28, 2008 at 11:26 PM, coc.kiest <coc.kiest@...> wrote:
> > Hi geeks,
> >
> > Is it appropriate to pass database transaction across different
> > repository objects?
> Yup, you will gonna need Unit of Work pattern [fowler].
> 
> I usually give a parameter for unit of work in the repositoriy
> constructor like this:
> 
> IUnitOfWork unitOfWork = new UnitOfWork();
> 
> IEmployeeRepository employeeRepo =
> RepositoryFactory.Create<IEmployeeRepository, Employee>(unitOfWork);
> 
> and some where beneath the factory function:
> 
> RepositoryFactory.Create<TRepository, TEntity>(IUnitOfWork 
unitOfWork) {
> .
>     return new EmployeeRepository(unitOfWork);
> .
> }
> 
> My UnitOfWork actually doesn't know how to manipulate the database, 
it
> just commit the appending transaciton.
> 
> If you wanna full source code for this kind of solution, maybe you 
can
> find Tim McCarthy's SmartCA at Code Plex.
> 
> regards,
> 
> Dicky Arinal
> Developer @ Transavia Indonesia
>

------------------------------------

SV: How it all fits together

Re: SV: How it all fits together

Tomas Karlsson wrote:
> I strongly recommend annotations of the Domain objects as the 
> persistence mechanism. OK, there will be a connection between the pure 
> domain and the persistent storage of the object. But in real life, how 
> often do you change persistence mechanism in a project. Keeping 
> everyting in the same source code file (and avoid the hbm.xml files) is 
> a higher value than a strict application of DDD in its purest form.

One question is, where do you draw the line when it comes to domain 
object metadata. For example, where do you put the labels to be shown in 
forms for a fields. Also in an annotation? What if it needs to be in 
many languages? Icon references? These kinds of things might be better 
to keep outside of the code, in Resource Bundles (if we're talking 
Java). But then, if you have that, would it then make sense to also have 
persistence mappings in Resource Bundles so as to have all metadata in 
one place?

/Rickard

------------------------------------

Re: How it all fits together

Thank you all for you insights.

I'm still considering the DAO though, I implemented the generic DAO as
illustrated by Java Persistence With Hibernate, and it seems to
combine CRUD operation with persistence operations (Persist, Make
Transient). Maybe thats the separation. 

However, even if the pure dao operations belong with the domain logic,
where do they fit in? Should the "Employee" entity have a static
"FindByID" method?

Still confused but getting there..

------------------------------------

Re: Database transaction of the Repository?

Re: SV: How it all fits together

RE: SV: How it all fits together

Re: SV: How it all fits together

randy.stafford <at> oracle.com wrote:
> Exactly.  I too prefer the separation of concerns achieved by keeping 
> O/R mapping metadata separate.  When I look at domain model code, that’s 
> what I want to see: domain model code.  The literate programming idea 
> implemented by javadoc is great, but somewhere along the line, with 
> xdoclet and JSRs 175 and 220, things got out of control.  I imagine 
> there are probably some great uses of annotations to include metadata 
> that is highly cohesive with the domain model but, as Rickard asked, 
> where do you draw the line?  One place I’d draw it is between domain 
> model and persistence; those are separate concerns.

I should add that I often begin my lectures by saying sorry for XDoclet 
 It seemed like a good idea at the time, but now it more seems like a 
workaround for bad design patterns... oh well..

Anyway, it seems to me that this lack of a unified way to do metadata, 
and to consider the different phases (development, packaging, 
deployment, production, etc.), is something that is forcing us to do all 
sorts of workarounds, including annotations. There's gotta be a better way.

/Rickard

------------------------------------

Spring in the Context of DDD

Hi,

    I've been exploring Spring.net recently and one thing that sticks
out to me is the call to GetObject().  It got wondering, are people in
practice using spring within the domain? Are folks putting these calls
in their domain objects, in the factories of their domain objects? Perhaps
Spring is best used to wire together layers? (e.g. wire up services in
your controller or page)
What's your opionon on the role of spring within a DDD project?

--

-- 
Cheers,
Aeden

------------------------------------