this is a bit ot... (my bit :) On Wed, 5 Dec 2001, Vincent Harcq wrote:
> I agree the data-object as itself is not really helpful when trying to > build more and more ejb with relationships between them and having to > return different kinds of data-object. > The spec even recommends that client view of an entity is not related to > the internal of the entity itself, what could simply says that > data-object sucks. > If you have an Order and OrderLine ejb (and a Product and a Pricing, and > ...), you can have a lot of data object to maintain by hand, xdoclet > could find a place here to help build automatically this data-objects. > First I would say that generation of data-objects should be separated > from entity bean design. > Then if you use HashMap/XML to build them, a solution could be found. > Then a "mix" task could mix generated data-object (or HashMap inside > session or ...) and the entity bean to avoid re-coding everywhere. > Do you agree here ? so what is in the map? key/values of the entity state, or what? > I tried to do that using custom tags but I am very far from a good > solution. > I can only generate as much as data-object as I want when getter/setter > name on data-object match a getter method on entity bean. I did not > take relationship into account yet. > I can also say that a special detail object is constructed by direct sql > inside a "catalog" home method to avoid finder method overhead this is the bit that I'm really replying to... the way I see it, I dont see why the container isn't able to provide this sort of query support. so I thought, I'll have a look at what is involved in implementing it. I've dont a fair chunk in jboss already, haven't touched it for ages, 'cause we started using castor at work, but have recently looked at it again. essentially, for each container generated finder, there is a container generated querier... very non-spec, but basically if you put queryByFoo in your home interface, I look for findByFoo and use the same sql, and create data objects based on that. doing this without the n+1 overhead too. my real problem though is what to do with relationships... should I try to be super clever and do the sql for the joins, or should I just wear the performance hit of having to do multiple queries? personally I think something like this would go a long way towards removing criticism of entity beans... I suppose the reason I'm writing this here is that you guys seem to have different view of the whole data object thing, so I'm wondering if some of that might show me a better option. cheers dim _______________________________________________ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
