Yeah, I was also going to suggest that instead of adding this to the core and 
then throwing out (or not), we do it another way - create it as a separate 
project (either in Cayenne SVN sandbox, or maybe even on GitHub) and see what 
comes out.

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 . 

As for me, I *love* anemic models :) They simply reflect the DB and are fully 
reusable in various app contexts (editable vs. read-only objects, cache vs. no 
cache, etc.). All my past attempts to define data objects with "business" 
methods were futile waste of time. 

But on the other hand, I wouldn't mind if there are choices of API. I can see 
some people more comfortable with setting up CayenneFilter in web.xml (for 
thread context), and staying in the AR sandbox afterwards. Maybe their 
requirements are more simple or something. And I am sure we'll learn from this 
experience too.

So I'd encourage all this new creativity around Cayenne, but defer decisions on 
the inclusion in our official releases till there's code to try out and users 
who give us feedback. 

>> From my estimates - we spent on development ~ 1 week, i

That's what I thought too 10 years ago when we started on Cayenne ;)

Andrus


On Dec 26, 2012, at 6:16 PM, Aristedes Maniatis <[email protected]> wrote:
> On 23/12/12 3:52pm, Дробеня Илья wrote:
>> From my estimates - we spent on development ~ 1 week, if
>> during year this feature do not will be used by anybody - we may remove it.
>> What do you think?
> 
> Sure, as long as you keep this as a wrapper outside of Cayenne itself. 
> Although measuring usage in an open source library is extremely hard, there 
> is value is creating more options for users.
> 
> Perhaps I misunderstood your idea... would your wrapper create a singleton 
> Context that lives for the life of the application or one per persisted 
> object?
> 
> Ari
> 
> -- 
> -------------------------->
> Aristedes Maniatis
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A
> 

Reply via email to