One advantage as I see it of making such wrapper classes is that you get
wrap SQLExceptions into your own custom Exception in just one place rather
than having to do a try/catch block which wraps the exception in every
method that accesses a database. This alone was worth it for me. It made
code much neater and readable. Same goes for logging.
As for cost of training and your other points about programmers not
understanding an in-house API right off-the-bat, I think you're somewhat
exaggerting the issue. I'm not radically changing the API (or even
modifying it really) at all, the methods can still have the same name (and
even the same parameter names!) so I don't see how it can cost a company
money. Besides, if a programmer is so inclined to do so, they can always
call something like Globals.getSqlMapClient() to do stuff manually.
Wrapping certain methods provided by SqlMapClient sure beats the hell out of
doing log.isDebugEnabled(), log.isInfoEnabled, try/catches in every method
that calls a db.
Just my $.02 on the subject as a guy who's trying to get there. :-)
Zarar
----- Original Message -----
From: "Larry Meadors" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Wednesday, July 13, 2005 10:04 AM
Subject: Re: queryForList not returning null
Where I work, we did that too, and it used to be one of our
development standards. In fact, I was a leading proponent for the
decision.
However, we stopped when we realized that there are two choices you
can make when you go down that path:
1) Mimic the existing API as closely as possible.
2) Change the API so that it suits your tastes better.
Both when you look at them closely add very little value.
In the first case, you add very little value, but gain the ability to
hire help that can quickly learn the API, especially if they have used
the wrapped API. the downside is that you create a bit more code to
maintain.
In the second case, you may improve the API, but you add more code and
documentation to maintain, and it comes at the expense of training -
you will never find a developer off-the-shelf who knows your API.
Finding developers who know the SQLMap API is not difficult.
In BOTH cases, it only ever matters if you change the API frequently,
which i think everyone agrees is not a great idea.
Just my $.02 on the subject as a guy who has been there, and done that.
:-)
Larry
On 7/13/05, Zarar Siddiqi <[EMAIL PROTECTED]> wrote:
What I do is that I have a base class (BaseDAOSqlMap) which encapsulates
all
my data access. In it are methods like getList(String,Object) which
calls
queryForList which allows me to define custom behavior of what getList()
returns. That way if the implementation for queryForList() changes (I
know
its unlikely), I have to change my code in one place. Just a thought.
Zarar
----- Original Message -----
From: "Kinjal Sonpal" <[EMAIL PROTECTED]>
To: "iBatis mailing list" <[email protected]>
Sent: Wednesday, July 13, 2005 6:32 AM
Subject: queryForList not returning null
> Dear All,
>
> Today while using queryForList method, I realised that if there are no
> records in the resultset, it returns an empty list unlike
> queryForObject (which returns null). Is it an undocumented feature or
> that's how it should have been?
>
> After each call, I have to manually check for the size of the list.
> Are there any known workarounds? Could not find much information over
> the internet or ibatis website/lists.
>
> Please advise.
>
> Thanks and regards,
> Kinjal
>
