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 <a...@maniatis.org> 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":http://en.wikipedia.org/wiki/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 >
