On Mon, 19 May 2008 09:19:26 +1000
Aristedes Maniatis <ar..sh.com.au> wrote:
> There should be something coming soon with inheritance, but there were
> no plans to support persistent objects with no database backing at
> all. There is going to be the opposite concept: abstract classes which
> have a database table, but which can only be constructed in their
> subclass.
>
> Tell us more about why it would be useful to have data objects which
> cannot be persisted to the database.
I guess my usage scenario is very specific to my environment. But let me
introduce my environment and let you decide.
I have written a UI renderer and data binding engine (Gozer). For that
engine to work I introduced the Domain Model, Table Module and Record Set
patterns and DataObjectKeys to Cayenne (at least to some extent). I did so
with my own code generator which generates datarows, datarowkeys and table
modules to every ObjEntity modeled with the Cayenne modeler.
For the data binding I use then these table modules. Let's say I have a
table with users. I can then bind that table to the UI like that:
<list databinding=..ser">
<list_field databinding="username" />
</list>
My UI engine is interpreting the binding information so that the UI
renders a list of users with the only field in the list containing the
username.
Which means that whenever I display data on the UI, I am using the same
databinding which makes use of my datatable and datarow objects.
Now to the QueryTable problem: Many applications have some form of user
input where a user can enter search criteria and then use that criteria to
filter a list of records or search data in the database. Since my UI
engine knows how to render my table modules and datarows, I would love to
use the same mechanism for query interfaces (a huge time saver).
To extend my example from above: I could introduce a UserQueryTable with a
field UserName. I could then define a view which binds that table. The
user enters a username and when clicking on the search button I could read
the content from the UserQueryTable and construct the query from the
content of that table. Side effect, all my queries would be
"standardised" and whenever I need to search for users in my application
I can use the same interface (UserQueryTable) which is then sent to the
UserQuery Business Object which handles the querying in a central
location (domain model pattern).
Of course I could solve that problem in creating ObjEntity which have
a corresponding table in the database (which is never used). But I find
this to be very ugly...
Hope this explained my scenario.
Cheers,
Adrian
This archive was generated by hypermail 2.0.0 : Mon May 19 2008 - 02:18:48 EDT