Thanks Wouter for the reply to make this tread active :-)
Judy
Wouter van Reeven wrote:
> Kristian,
>
>
> Why is depending on Spring such a big problem? Only because it's not "pure JEE"?
> Have you considered using Ibatis? It's not real JPA, but not plain JDBC either.
>
>
> HTH, Wouter
>
> On Wed, Mar 18, 2009 at 09:51:29PM +0100, Kristian Rink wrote:
>
>> Folks;
>>
>> in a current situation we are messing with performing a smooth migration
>> away from a "legacy", pretty much mixed-up database (well, "table"...) and a
>> proprietary (non-Java) document management system on top of that to (which
>> is at least what we're aiming for, so far) an application platform mainly
>> consisting of services utilizing standard Java EE technologies to keep
>> applications sane, slim and maintaineable (i.e. trying to avoid third party
>> dependencies).
>>
>> However, in a given situation and for a given use case, I do have a problem
>> like this to solve: In part of our database, tables are merely used alike
>> "Excel spreadsheets" - if in doubt, a new column gets added and eventually
>> filled with content, making a sane O/R model a difficult thing to have...
>> However, this is how things work there, and the best way I could come up
>> with to access this from within Java is to fetch rows of these tables to
>> Map<String,String> objects, key set being the column names, and values being
>> the appropriate values in the column for right that cell in the row. I so
>> far have found several solutions to this:
>>
>> (a) Use Spring and the SimpleJdbcTemplate helper class. This is what we so
>> far do in part of our Java integration code, and it works just like that
>> (returning a table row using something like a "queryForMap" method), of
>> course at the price of being dependent upon Spring and its dependencies
>> rather than just using pure Java EE.
>>
>> (b) Use JPA. This would be our favorite solution for Java EE purposes and
>> also because JPA is, well, the standard persistence technology that comes
>> with Glassfish. So far however, I found that doing this kind of work (pretty
>> "native" SQL operations away from persisting / retrieving defined entities)
>> is rather difficult; the best I managed to do so far is retrieving a table
>> row as an Object[] containing the different cells yet omitting the
>> corresponding column names, thus requiring additional work to get right this
>> information and ensure the right data ends up in the right place, in the end.
>>
>> (c) Use plain JDBC. This eventually would allow for doing what I need and
>> also eventually be the most straightforward solution, of course at the price
>> of being more low-level.
>>
>>
>> So, overally, I can't really make up my mind what to do here... stay with
>> Spring (what we so far use and what, so, "basically is around"), go for JPA,
>> or use plain JDBC in this part of the application? What do you think?
>>
>> Cheers & best,
>> Kristian
>>
>> --
>> Kristian Rink
>> cell : +49 176 2447 2771
>> business: http://www.planconnect.de
>> personal: http://pictorial.zimmer428.net
>> "Past midnight. Never knew such silence.
>> The earth might be uninhabited..."
>> //beckett / krapp's last tape//
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: quality-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: quality-help_at_glassfish.dev.java.net
>>
>>
>
>