Also FWIW, we are trying to build the same fluent APIs in Cayenne itself, so to
me Ilya's proposal is simply reassigning the existing and planned query APIs to
objects themselves - a very simple "transposition".
I.e. this proposal is just a different style for what we already have or will
have
I think the idea is to combine the new API with existing Cayenne facilities for
providing thread-bound ObjectContext based on some custom strategy (e.g.
CayenneFilter [1]) and then using the API within a single thread context. And
committing via a single static class (instead of committing indiv
You are right. You can build rich models on top of Cayenne objects, either
yourself and/or with the help of generation tools suggested here (although the
tool would only be able to provide data access methods based on semantics). And
this is great and herein lies the power of the generation gap
On 26/12/12 6:48pm, Дробеня Илья wrote:
This is the best OOP design. And for me need to separate context only when
we need anvanced features that do not possible in current design.
Let's take:
a.delete()
b.delete()
a.commitChanges()
Are there two separate contexts there so I committed only th
@Дробеня Илья The 4 samples you put are far too easy to implement with a
mix of special templates (por findAll, query and newInstance) and a
non-standard SuperClass (for delete operation)
I've already tried that, and it works, but its not silver bullet...
Once you tried that, you want properties f
Pardon my ignorance, I really don't understand what do you mean with
>>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 don't know anything about WO :(
I would really apprec
Why AR is simpler than row data gateway (that used in cayenne).
Examples,
1.
SelectQuery select1 = new SelectQuery(Painting.class);
List paintings1 = context.performQuery(select1);
vs
Painting.findAll()
What is simple?
2.
Expression qualifier2 = ExpressionFactory.likeIgnoreCaseExp(
About my experience.
I took part at projects where used all 3 wideused models.
1. Project with Anemic Domain Model - insurance automation
Technologies: WebSphere Portal + Spring + Hibernate
Technology is working, all good. But classes is really big - business logic
is not reused and very complex
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 man
@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
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 busi
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
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 beh
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
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
15 matches
Mail list logo
