James, you have a couple of really good points there, I can't unit test
as easily as you would with ORM, but keep in mind that I'm talking about
mostly legacy queries that I would otherwise need to rewrite completely.
For some complex stored procs I have scripts that create copies of the
affected db objects, fill them with test data and evaluates the result, but
this is obviously not a good or maintainable solution. I do intend to try
dbunit, but had not time to do it yet.
And yes, there is kind of a nightmare since there is a big deal of
reports and listings with cross referenced data, and everytime there are
changes in the database structure, a lot of them need to be tested to be
equally valid against old data and new data.
Some of this could be alleviated by other reporting tools, but I fail to
see how ORM would be of any help for this. I would say most of web
applications' data don't follow this pattern and are best suited for ORM,
but some data is inherently relational, set based, and forcing them through
ORM doesn't sound to me like a good choice. It's a fact that all ORMs out
there allow you for "back door queries", if you allow me to state it this
way, when performance is an issue or the SQL is fairly complex.
This is why I pointed out that there is no silver bullet and that the
right tools may vary according to the requirements.
Cheers,
Daniel
James Carman-3 wrote:
>
> On Tue, Oct 6, 2009 at 12:32 PM, dtoffe <dto...@yahoo.com.ar> wrote:
>> So our fast and easy way is to use code generation to get JDBC based
>> DAOs that wrap the stored procs call. We even keep writing stored procs
>> for
>> new requirements, all our devs know SQL well and I don't believe we will
>> gain anything by using Hibernate instead.
>
> How do you unit test? How do you keep the stored procedures and your
> Java code in synch? I only ask because I've seen that sort of set-up
> at a client before and they had a nightmare of a time keeping things
> straight and making sure they didn't break other things when they
> changed their stored procedures. For me, I like to keep my logic out
> of stored procedures as much as I can.
>
>
--
View this message in context:
http://www.nabble.com/How-do-you-achieve-persistency-tp25765566p25776405.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
