|
From: <jue...@we...> - 2004-01-05 13:23:06
|
Michael,
=20
I can understand your concerns. But JdbcDaoSupport still belongs in the =
main framework: It is not meant to be a base class for customized DAO =
base classes but rather a convenience base class for concrete DAOs. In =
all other cases, use straightforward DAO implementations that expose =
their dependencies, or create your own base class that accepts a =
DataSource and/or JdbcTemplate instance. We should probably clarify this =
in the Javadocs.
=20
Why exactly do you want to override JdbcDaoSupport's methods? The only =
thing that I can imagine is using your own subclass of JdbcTemplate: You =
could achieve this easily by setting up your JdbcTemplate instance in =
the application context and passing it to JdbcDaoSupport's =
"jdbcTemplate" property - actually, pre-configured JdbcTemplate =
instances is exactly what that property is for.
=20
JdbcDaoSupport is really a *very simple* convenience base class for =
standard JDBC-based DAOs, so I don't consider it inappropriate to create =
your own class here... (your own class can even derive from any other =
base class then). And if you don't set a pre-configured JdbcTemplate =
anyway, you just need setDataSource and getJdbcTemplate methods.For =
example, with a custom subclass of JdbcTemplate:
=20
public abstract class MyJdbcDaoSupport {
=20
private JdbcTemplate jdbcTemplate;
=20
public final void setDataSource(DataSource dataSource) {
this.jdbcTemplate =3D new MyJdbcTemplate(dataSource);
}
=20
protected final getJdbcTemplate() {
return jdbcTemplate;
}
}
=20
The same applies to HibernateDaoSupport, JdoDaoSupport, and =
SqlMapDaoSupport: They are all supposed to serve as convenience DAO base =
classes for *typical* scenarios, to be replaced by custom base classes =
or no base classes at all in case of special requirements.
=20
Juergen
=20
________________________________
Von: spr...@li... im Auftrag =
von Michael Young
Gesendet: So 04.01.2004 19:54
An: spr...@li...
Betreff: Re: [Springframework-developer] Re: Final methods in SqlQuery
Rod,
Sorry about my confusion. Actually, what I had to work around
JdbcTemplate is not the issue of final methods. There aren't
any final methods in JdbcTemplate that I want to overwrite.
My issue was the following:
I want to overwrite afterPropertiesSet() in JdbcTemplate so that
it won't call getExceptionTranslator() immediately when a
datasource is being set. This is because my datasource is a wrapper
for a bunch of datasources, so the real datasource is not known
until it's actually used.
This is why I have to overwrite afterPropertiesSet() in my subclass
of JdbcTemplate.
I was also using JdbcDaoSupport but its JavaBean set and get methods
are all final, and this is the issue I was complaining. I have to
create my own class rather than extending from JdbcDaoSupport. This
is OK, but I really don't like the idea of methods being final
when there are no such needs/benefits from it. JdbcDaoSupport is
not a crucial class in the framework, but that doesn't mean that
we shouldn't take care of it just like those important classes
in the framework. It may be a trivial and unimportant class to
you, but it was important to me because I was using it. And it
may be important to others as well. If we are supposed to write
our own rather than extending from it, then maybe it should not
belong there. Maybe it should be in one of those sample apps.
I'm not really complaining, but just hope for improvements in Spring.
Thanks! /Michael.
On Friday, Jan-02-2004 10:12 AM (PST) rod...@in... (Rod =
Johnson) wrote:
> I don't object to making more methods non-final, as people do ask for =
this.
>
> However, in general I think there are better extension mechanisms than
> overriding methods in Spring in many cases. I don't particularly like
> overriding concrete methods as a means of extensibility.
>
> Why would you want to subclass JdbcTemplate?
>
> Why would you override JdbcDaoSupport's methods?
>
> I'm not being sarcastic, I'm just curious...
>
> Regards,
> Rod
>
> ----- Original Message -----
> From: "Michael Young" <sp...@on...>
> To: <spr...@li...>
> Sent: Friday, January 02, 2004 5:42 PM
> Subject: Re: [Springframework-developer] Re: Final methods in SqlQuery
>
>
> Juergen,
>
> Can you do the same for other classes as well? Classes such as
> JdbcTemplate and JdbcDaoSupport. Someone also mentioned the
> abstract wizard form controller as well. See messages previously
> posted either here or in users.
>
> Thanks! /Michael.
>
> On Friday, Jan-02-2004 02:45 AM (PST) jue...@we... =
(j=FCrgen
> h=F6ller [werk3AT]) wrote:
>
> > This sounds plausible to me. I'll look into turning appropriate =
methods
> non-final today, if noone objects.
> >
> > The original rationale behind the final methods is to offer clear
> extension points: Subclassers should know which methods are intended =
for
> overriding and which are not, avoiding confusion. But I agree that =
this
> doesn't work for cases that the framework developers didn't expect, so =
it's
> probably better to not use final for methods where there is no clear =
general
> extension hook. I've already applied the same principle in the bean =
factory
> implementation hierarchy.
> >
> > Juergen
> >
> >
> > ________________________________
> >
> > Von: spr...@li... im =
Auftrag von
> David Heimann
> > Gesendet: Fr 02.01.2004 02:24
> > An: spr...@li...
> > Betreff: [Springframework-developer] Re: Final methods in SqlQuery
> >
> >
> >
> > Ken and developers,
> >
> > I have a business rule in my system that all the data be
> > stored in upper case in the database. This sugests the
> > following design:
> >
> > 1)This is a business rule and so should be in the model
> > layer rather than the presentation layer
> >
> > 2)The code to upper case the data should be centralized.
> > Requiring each developer to upper case the data before
> > calling the execute or update methods duplicates code and
> > is error prone. (the PetClinic sample has around 12
> > execute or update calls, each of which would need to be
> > prefaced by upper casing code)
> >
> > 3)This suggests a design where I extend SqlUpdate and
> > SqlQuery and override the SqlUpdate.update and
> > SqlQuery.execute methods, for example
> >
> > public abstract SqlQueryUpper extends SqlQuery
> > {
> > public List execute(Object[] parameters, Map context)
> > throws DataAccessException {
> > //upper case string parameters
> > for(int i =3D 0;i<parameters.length;i++)
> > {
> > Object p =3D parameters[i];
> > if(p instanceof java.lang.String)
> > {
> > parameters[i] =3D p.toUpper();
> > }
> > }
> > return super.execute(parameters, context);
> > }
> > }
> >
> > Of course, I could create my own method with a different
> > name such as
> > ...
> > public List executeUpper(Object[] parameters, Map context)
> > throws DataAccessException
> > {
> > (same as above)
> > }
> >
> > But if I do that, then I
> > 1)Still have the original SqlQuery.execute method out
> > there which no one should use.
> > 2)Do not have all the other signatures available such as
> > SqlQuery.execute(int), SqlQuery.execute(String) etc because
> > they all still go through the original execute method.
> >
> > Finally, my problem is an example of something not included
> > or anticipated by the developers of the Spring Framework.
> > There is no built in Spring 'auto-upper' option nor should
> > there be. Putting final on methods stops me from adding it
> > myself, making the framework unextendable in this area.
> > IMHO final methods should be few and far between in an
> > extensible framework and I do not think they are called for
> > here.
> >
> > Sincerely,
> >
> > David Heimann
> >
> > >David,
> > >
> > > I don't understand why you think it would be nice to
> > ***override*** it.
> > > The execute method does all the IOC hard stuff for you.
> > If you override
> > > it, you have to do this yourself, adding unnecessary
> > duplication. That's
> > > why it's final. The same goes for SqlUpdate.update. In
> > your example, why
> > > not simply manipulate the parameters to your heart's
> > content before
> > > passing them to the execute method ?
> > >
> > > Ken
> > >
> > > Heimann, David X - San Mateo, CA wrote:
> > >
> > > > Developers,
> > > >
> > > > Could you change
> > > >
> > > > *public** final* List execute(*final* Object[]
> > parameters, Map context)
> > > > {
> > > > ...
> > > > }
> > > >
> > > > in org.springframework.jdbc.object.SqlQuery to not be
> > final ? It
> > > > would be nice to overload it, for example to change all
> > parameters to
> > > > upper case before executing. The similar update method
> > in SqlUpdate
> > > > is not final. Why be final at all ?
> > > >
> > > > David Heimann
> > > >
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > Find out what made the Top Yahoo! Searches of 2003
> > http://search.yahoo.com/top2003
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: IBM Linux Tutorials.
> > Become an expert in LINUX or just sharpen your skills. Sign up for =
IBM's
> > Free Linux Tutorials. Learn everything from the bash shell to sys =
admin.
> > Click now! =
http://ads.osdn.com/?ad_id=3D1278&alloc_id=3D3371&op=3Dclick
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > =
https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: IBM Linux Tutorials.
> > Become an expert in LINUX or just sharpen your skills. Sign up for =
IBM's
> > Free Linux Tutorials. Learn everything from the bash shell to sys =
admin.
> > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id371&op=3Dclick
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > =
https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills. Sign up for =
IBM's
> Free Linux Tutorials. Learn everything from the bash shell to sys =
admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id371&op=3Dick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills. Sign up for =
IBM's
> Free Linux Tutorials. Learn everything from the bash shell to sys =
admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id371&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for =
IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys =
admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id371&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|