I'd not worry about crafting a strict Object heiarchy. I've yet to see a perfect Domain object model that mimics all these relationships, etc. Especially when trying to mimic that of a relational database. What tends to happen is that you optimize for your domain model at a given point in time, then 6 months later a new feature requrest comes in and there's no way to elegantly support it. So then you need to add it on anyway.
Think of the VOs in your Flex application layer as Working UI VOs and not necessarily that of a perfectly modeled domain. And then you need to take into consideration when someone really needs to have the sub-objects of the parent. Sometimes they're needed, sometimes they're not. I tend to use more controlled bulk getting of data and map it to custom VOs for that specific purpose. I.e., sometimes on one Pet listing screen, I need 10 properties to help filter for pets on. On another I could need 15 more, along with a list of immunizations for those pets. Instead of trying to make one VO and one set of data access work for both, usually resulting in too much thought and sacrificing performance in each use case, I'll just craft a couple different VOs PetListingVO PetsAndTheirImmunizationsVO and go with it. Sometimes a bunch of data needs to be batched up and sent to the server for an update. Sometimes it's perfectly fine to send the updates individually. Something like that anyway. I've worked in a lot of large Financial types of applications where we've always tried to get a perfect Domain model, and have yet to see it work. There's usually too many fringe cases. Too many optimization tweaks thrown in, etc. Inheritance for VO mapping is usually an unnecessary complexity. --- In [email protected], Kevin <[EMAIL PROTECTED]> wrote: > > I completely agree with the Hibernate "a lot of joins" issue. I look > at some of these queries and it's a little nuts. On the other hand, > we are deep into using Annotations with Hibernate which has been much > easier for us to maintain than the mapping files. I'll have to take a > look at iBatis and see how good a fit it would be for us in the > future. (It might be too late to migrate over now unless we found it > absolutely necessary for performance). I am assuming you had to > write your own assembler for that OR is there one publicly available > to integrate with DataServices? > > As far as inheritance issue, ironically, the overloaded PetVO with > the pet type property is how I have dealt with this in the past > (..but I have also always written my own db queries). I find it a > little messy on the client since you end up having to keep track of > what properties go with what, but it works and was very efficient. > On this project I decided to try my hand at programming everything > from a more strict Object perspective and seeing if Hibernate could > handle the rest... Hibernate seems to be doing ok (remains to be > seen), but I am running into some limitations with DataServices. > > I'll keep poking at this and see if I can apply some of your > suggestions without completely abandoning out data model. > > Thanks, Kevin > > > > On Dec 15, 2007, at 6:33 PM, simonjpalmer wrote: > > > I had the exact same problem, I think the issue is not really > > inheritance but the graph of objects being arbitrarily complex and > > deep. > > > > I got round it by ditching the managed associations completely and > > going for RPC calls to my Java classes using RemoteObjects. I found > > myself too tangled by the destinations and weird and undesirable > > behaviour of the framework that I had no control over. > > > > In my case a close examination of the reality of the usage of my > > object model showed that I rarely had a true cyclic graph and in fact > > towards the edges it was much more like a directed acyclic graph, so I > > constrained the application to enforce that and altered the server > > transaction to lift the graph in little hierarchies rather than as > > individual components. I think it is always a good idea to make sure > > your model fits exactly what you are doing rather than some potential > > fringe use cases at the cost of complexity. You have probably done > > that already. > > > > The suggested solution of separating the objects and the relationships > > is a great idea as well, and you can reconstitute it quite easily on > > the client side if you need to. This is probably my next major > > architectural overhaul. On the client the use of a Dictionary or > > Object as a proxy for a hash map offers some interesting architectural > > opportunities. > > > > As an aside I also found that very deep hierarchies of objects caused > > Hibernate to create a lot of joins and or inefficient sub-queries and > > it was impractical for my purposes from a performance standpoint. I > > found iBatis a much better fit because 1) I have SQL expertise and 2) > > I don't have the issue of having to make sure my persistence tier > > works on all known rdbms's so I could take advantage of some db > > specific features. > > > > --- In [email protected], "Josh VanderBerg" <yahoo@> > > wrote: > > > > > > I tend to eschew implementing inheritance in data model that > > needs to > > > be persisted to a database - preferring (in this example) instead to > > > overload PetVO with all of the possible pet properties and give it a > > > petType property. Regardless of whether or not you implement > > > inheritance, the PetVO must have a property: > > > > > > public var friends : ArrayCollection; > > > > > > In the database you will have to have a table something like the > > following > > > > > > PetRelationship > > > > > > relationship_id INT (Autonumber) - surrogate key > > > pet_id INT - FK Pet table > > > friend_id INT - FK Pet table > > > > > > And use it to do your data services mapping, and map it > > appropriately > > > in Hibernate as well (if that's what you are using). You could > > > optionally expose this object as an endpoint itself, so it would be > > > the home of the "friends" lists. In this case the PetVO would just > > > have a property: > > > > > > public var relationship : PetRelationship; > > > > > > And your mapped PetRelationShipVO would store the ArrayCollection of > > > friends. > > > > > > Now, the application of either would be relatively obvious in the > > case > > > where you don't implement inheritance in the datamodel. I am sure > > > there is a way to do it with inheritance - I've just never done it - > > > but the approach would be similar, you really need a many-to-many > > > mapping table at the PetVO level. > > > > > > __ > > > Josh Vanderberg - vanderblog.typepad.com > > > > > > --- In [email protected], Kevin <lists@> wrote: > > > > > > > > DataServices experts, > > > > > > > > We are currently stumped on how to configure our data-management > > > > config to address a very specific data model that we have. I would > > > > love to get some ideas/feedback on how to solve this dilemma. Here > > > > is our problem (as simplified as possible). > > > > > > > > We have a number of objects that extend a root object like so: > > > > > > > > PetsVO(root object) > > > > extended by: > > > > - DogVO > > > > - CatVO > > > > - BirdVO > > > > - FishVO > > > > - RatVO > > > > > > > > Here is the problem. Each object can hold a collection of pet's > > > > objects. So in a social networking way, each pet can be linked to > > > > its pet friends. > > > > DogVO > > > > - holds collection of PetVO's > > > > CatVO > > > > - holds collection of PetVO's > > > > BirdVO > > > > - holds collection of PetVO's > > > > ... you get the idea. > > > > > > > > So, how do with deal with this in our destinations?? > > > > > > > > Option 1) Hierarchical management. > > > > - This works conceptually of course since no association tags are > > > > required to link the destinations together. However, we then have > > > > major scaling issues & no way to throttle individual destinations, > > > > etc... Not really a working solution unless your model was > > truly as > > > > simple as the one I am describing. > > > > > > > > Option 2) Use destinations to manage relationships. > > > > > > > > We set up destinations for each of these sub classes: > > > > dogs > > > > cats > > > > birds > > > > fish > > > > rats > > > > > > > > However, how do we associate the PetVO collection in each? > > > > > > > > <many-to-many property="pets" destination="???????" lazy="true" /> > > > > > > > > THOUGHT 1: If we have a pets destination and set up a "many-to- > > many" > > > > tag from "dogs" to "pets" then we create the problem where we are > > > > managing the same object in two different places. Plus when we > > add a > > > > "CatVO" to a "pets" collection in a "dogs" destination (as an > > > > example) DataServices initializes a createItem in the "pets" > > > > destination not knowing that the object already exists as part of > > the > > > > "cats" destination...not good. > > > > > > > > THOUGHT 2: We could set up a "many-to-many" tag in dogs to > > > > "cats"...however this obviously won't work when someone then > > adds a > > > > BirdVO to the collection. > > > > > > > > What to do?... I realize this is a silly example, but hopefully it > > > > illustrates the problem of integrating an object model which > > uses a > > > > lot of Base or Root objects into DataServices. > > > > > > > > Is there something we are missing or not understanding about > > how we > > > > could set this up? I would be interested to see if anyone has any > > > > solutions. > > > > > > > > (I should note that we are using Hibernate with Annotations.) > > > > > > > > Thanks for your help we look forward to any of your ideas, > > > > > > > > Kevin > > > > > > > > > > > > > >
