cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Juan José Gil <>
Subject Re: Add ActiveRecord support to Cayenne
Date Wed, 26 Dec 2012 21:32:36 GMT
@emeka, in that regar of having rich models, how are you resolving the
injection of services in your models? Or are you accessing your
dependencies using static factories?

@Дробеня Илья, in some pet projects I was using some very "powered"
templates, wich constructs me metadata in my models and i use that for
accessing fields at models (as some kind of reflection, but without the
mess of java), query building, etc... but, after many tries, I don't think
that java is the rigth lang for this kind of programming (too wordy), maybe
cayenne+scala or cayenne+groovy would be a nice try ;)

2012/12/26 emeka okafor <>

> I am a little bit surprised that you call the cayenne way "anemic domain
> model". I do not see what is anemic in this case.
> /rant
> The fact that a domain object has the ability to call save() on  itself or
> not has nothing to do with anemism or richness. In cayenne you can and
> should put your business logic in your domain objects. You only have
> problems when you have to integrate with all the j2ee stuffs. They have
> services all over the place, they create interfaces for everything (Spring
> really pushed the enveloppe very far in that regard) because the
> implementation may change somewhere in the future. As a result You have
> your DAO implemented as a service and have to pass objects id to that
> service to traverse relationships. Really unless you are having scaling
> problems, the DAO as a service thing is weird. I was fortunate to work with
> webobjects after a couple of years doing all the jee stuffs and only after
> that did I learn what real domain driven design means, because it was
> natural. No need for weird interfaces, weird pojos, weirds annotations. Now
> what does it have to do with
>  active records, actually nothing. It is just that someone said that with
> cayenne you have an anemic domain model, which is not true.
> /end of the rant
> ________________________________
>  From: Andrus Adamchik <>
> To:
> Sent: Wednesday, December 26, 2012 6:25 PM
> Subject: Re: Add ActiveRecord support to Cayenne
> In ROP case the root cause is 2 separate disjoint models (doesn't matter
> rich or anemic). A single anemic model would've allowed to define a common
> set of "services".
> So while I am still on this rant, I think the "rich/anemic model"
> discussion at the end may come down to modularity
> requirements/expectations. One of the modularity paradigms is this:
> "coarse-grained modules are easier to use, but harder to reuse; and a
> corollary - fine-grained modules are harder to use, but easier reuse".
> For instance WO-world wasn't very keen on modularity, so rich models
> worked relatively well (or was it because the original Objective C
> implementation of WO allowed for categories to redefine existing classes in
> runtime? ;)). JEE and enterprise apps in general strive for better
> modularity so defining lots of business logic high up in your dependency
> tree is going to cause lots of pain.
> But then again, I admit not everyone is writing the same applications that
> I do :)
> Andrus
> On Dec 26, 2012, at 8:04 PM, Aristedes Maniatis <> wrote:
> > On 26/12/12 11:40am, Andrus Adamchik wrote:
> >> Ilya's point that we discussed a bit offline was that AR-like design is
> more object-oriented, with object providing all operations on themselves.
> The context will be taken from the current thread (something we already
> provide). One piece of theory behind it is a reference to the Fowler's
> criticism of "anemic domain model":
>  .
> >
> > I find this quite interesting. One problem we are trying to solve on our
> project right now is bringing together logic between the client and server
> entities in a ROP system. Because Cayenne entities inherit from different
> superclasses (what's with that?), it is very hard to keep the business
> logic in a one place.
> >
> > Anemic models are all very well, but what do you do with the code? It
> seems that all the options available to us aren't terribly convenient to
> use. We either end up with zillions of interfaces or lots of static methods.
> >
> > AR is the opposite of anemic. All the Rails projects I've seen tend to
> throw lots of code into the model. But because Ruby uses duck-typing
> instead of interfaces, things don't get quite so messy. Even searching is
> rooted in the model classes:
> >
> >   Artist.find(:name, "bob").sort(:age)
> >
> > or something like that.
> >
> > Ari
> >
> > --
> > -------------------------->
> > Aristedes Maniatis
> > GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message