It depends on what you call service. Is a service a message call that is remote in the sense that it is outside of the same JVM or is a service any random function that do not belong to the domain object? If I am working in a j2ee/spring environment i.e I want to use ejbs or have a container managed my objects, then you are right and I am going to have a problem integrating cayenne objects into that environment and will do all kind of gymnastic to accomodate for that, by creating fake pojos with wrapper and annotations so that the container can inject those services. In this case, my cayenne objects become naked(cayenne is not to blame for that). Personally I would rather program in groovy with metaprogramming than do all that stuff if I had to. Beside that I rather do simple stuffs like the webobjects guys do. You do not hear them complain about such things like services, and dependency injection and what not. I mean, last time I checked, Apple Itunes was running on a technologie similar to cayenne.
________________________________ From: Juan José Gil <mat...@gmail.com> To: user@cayenne.apache.org; emeka okafor <emeka_1...@yahoo.com> Sent: Wednesday, December 26, 2012 10:32 PM Subject: Re: Add ActiveRecord support to Cayenne @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 <emeka_1...@yahoo.com> > 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 <and...@objectstyle.org> > To: user@cayenne.apache.org > 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 <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 > > >
