Hi,
> this is a bit ot... (my bit :)
OK, I just wanted to kill this data-object problem.
Data-object pattern is a bad one, I am not the only one to say that.
Maybe I should position the problem first. This is well known imho,
anyway here it is:
It has been introduced when access to entity bean was only possible
through remote interface (ejb1.1) and access to each getter method
introduced remote calls (baaaad)
With ejb2.0 you can use local access and play with entity beans between
them, via session and mdb in same jvm (gooood)
They are still needed for client (web,swing,soap, ...) access to the ejb
container to "maintain" entities : create-read-update-delete.
This raises a tons of critics to data-object.
If I have internal attribute (say a field that store the time of last
modification) why should it be on the data-object.
If I have a Struts form that have 3 fields(day-month-year) for a date
that need to be stored in the entity bean why should the entity be aware
of that, and why should I not be able to create these 3 fields by
xdoclet in an automatic way if I have a web client but only one field if
I have a swing client
If I need a Collection of order data-object to show a list to the user
why should I need to put the lines inside this object if I don't show
them, but when I see one order then I need its order lines, so 2
different data-objects
Etc....
So why generate this data-object from entity beans ? It is a client
stuff not an entity one.
(continue below)
>
> 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 think so. Dan O'Connor write this pattern in a old JDJ issue, I think
it has been reintroduced by TSS.
XML aware value object is another one.
I do not pretend to solve this problem in a unified way as I don't see
xdoclet as another j2ee generation tool.
Though I believe we could evolve the data-object as it is today to
something a little more clever.
If this off topic for you all on this list, I will shut up :-)
>
> > 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.
Yep, a real Persistance Manager inside a EJB container, my dream ;-)
Jboss (hey that's the only where we can see the internals) is not far
from that,
You can avoid n+1 problem with read-ahead
You can cache entity bean with commit-option A
But it will hit the database for the query
And I still need to transform my collection of entity beans to a
collection of data-object to send to the client. If I early-load this
data-object inside the entity bean I can avoid the overhead, so come to
something as fast as direct sql.
> 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.
I Agree completely.
I have done that :-)
Blouf :
<XDtClass:forAllClassTags tagName="hm:datasource">
protected javax.sql.DataSource getDataSource(){
try{
javax.naming.InitialContext initial = new
javax.naming.InitialContext();
Object o = initial.lookup("<XDtClass:classTagValue
tagName="hm:datasource" paramName="jndi-name" />");
return (javax.sql.DataSource)o;
}catch (Exception e){
cat.error("Exception while JNDI Looking for DataSource",e);
return null;
}
}
protected java.sql.Connection getConnection()
throws java.sql.SQLException{
return getDataSource().getConnection();
}
</XDtClass:forAllClassTags>
<XDtClass:forAllClassTags tagName="jboss:table-name">
protected String getTableName(){
return "<XDtClass:classTagValue tagName="jboss:table-name"
paramName="table-name" />";
}
</XDtClass:forAllClassTags>
<XDtMethod:forAllMethods>
<XDtMethod:ifHasMethodTag tagName="hm:sql-field">
<XDtMethod:forAllMethodTags tagName="hm:sql-field">
protected <XDtMethod:methodType/>
sql<XDtMethod:methodNameWithoutPrefix/>(java.sql.ResultSet rs)
throws java.sql.SQLException{
return rs.get<XDtMethod:methodTagValue tagName="hm:sql-field"
paramName="type"/>("<XDtMethod:methodTagValue
tagName="jboss:column-name" paramName="name" paramNum="0"/>");
}
</XDtMethod:forAllMethodTags>
</XDtMethod:ifHasMethodTag>
</XDtMethod:forAllMethods>
<XDtClass:forAllClassTags tagName="hm:catalog-method">
<XDtClass:classTagValueMatch tagName="hm:catalog-method"
paramName="match"/>
public <XDtClass:classTagValue tagName="hm:catalog-method"
paramName="type" /> <XDtClass:classTagValue tagName="hm:catalog-method"
paramName="name"/>()
throws FinderException{
Connection con = null;
List ret = new ArrayList();
try{
con = getConnection();
PreparedStatement ps = con.prepareStatement("select * from
"+getTableName());
ps.execute();
ResultSet rs = ps.getResultSet();
while (rs.next()){
<XDtClass:classTagValue tagName="hm:catalog-method"
paramName="detail" /> detail = new <XDtClass:classTagValue
tagName="hm:catalog-method" paramName="detail" />();
<XDtMethod:forAllMethods>
<XDtMethod:ifHasMethodTag tagName="hm:detail-object">
<XDtMethod:forAllMethodTags tagName="hm:detail-object" >
detail.set<XDtMethod:methodNameWithoutPrefix/>(sql<XDtMethod:methodNameW
ithoutPrefix/>(rs));
</XDtMethod:forAllMethodTags>
</XDtMethod:ifHasMethodTag>
</XDtMethod:forAllMethods>
ret.add(detail);
}
}catch (Exception e){
cat.error("Exception",e);
throw new FinderException("An SQL Exception has occured :
"+e.getMessage());
} finally{
try{
if (con != null) con.close();
} catch (Exception ex){
cat.warn("Exception in SQL FINALLY block",ex);
}
}
return ret;
}
</XDtClass:forAllClassTags>
>
> 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?
I don't have that :(
Imnsho telling that we need an sql remapping for finder method is the
same as telling that entity bean is bullshit.
With a good container, finder methods should be as fast as writing sql
by hand
Does entity developement still need sql ? Yes
Will it make entity bean survive ? No
The developer should forget that a database is behind, should even not
know that a database is behind
The deployer have db knowledge and do the sql query with the info the
developer gives him.
>
> 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.
I tried to look at how externalize Jboss JAWS on my spare time to be
able to reuse it outside EJB.
If days could have 48 hours...
I think again MVCSoft/Daniel O'Connor (respect!) is going this way
Another way could be JDO as persitance maneger (inside ejb container)
>
> cheers
> dim
Regards.
Vincent.
------------------------------------
"Big Mouth Strikes Again" (Morrissey)
_______________________________________________
Xdoclet-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
