Been cutting my teeth and have developed a few small application examples using hibernate. Once I got the environment setup properly, it was very easy to get things working(especially using myeclipse to build my configuration files for me).

I have a question regarding maintenance on large scale enterprise wide applications using hibernate and was trying to illicit from veteran users implementing hibernate on an enterprise level on how easy it is to maintain the code over time especially in the areas of refactoring or stages beyond version 1.0 of a solution(i.e. how easy was it to go to version 2 or version 3? How easy is was it to implement a significant business model change when the existing model spans several configuration files? Doing impact analysis, moving/encapsulating properties into dependent objects after version 1.0. Say you changed your contracts between objects such that some objects no longer reference other objects(de-coupling)).

How easy is it to refactor data/behavior when a good portion of the references to properties of your objects exists in a configuration file especially when its most desirable to catch mapping issues at build time rather than runtime. Do you have tools or an easy methodology to avoid not catching references to properties that have changed or been removed in the configuraiton files?

Maintenance is something I believe is quite important especially on enterprise wide solutions. I can imagine having to manage 50-100 hibernate configuration files with string references to properties of our business model which can be refactored quite frequently and the potential risk of missing or incorrectly modifying configuration files in the refactoring process that may not get caught until it ends up in production(assuming it slips by our regression tool)

I guess I am a little hesitant because because, from my own experience, it seems better to keep code and behavior native to the OO-language. It would be easier to perform impact analysis, refactoring, catch problems with referring to data and/or behavior at build time

For example, anyone ever use the refactoring tool in eclipse? Its a beautiful thing. It tells you about your impact, shows your impact and offers to change your code if you like(the benefit of keeping data/behavior native to an OO language). What happens to the configuration files when I tell eclipse to refactor my classes after I come up with a better design? Is there an ecipse plug-in that refactors the configuration files tool so when I change the model, the files evolve? Thats probably a tough thing to do and I am guessing it doesnt exist?!?

I am not against hibernate at all. I just have no experience with what can happen downstream in terms of a software evolution. Perhaps this all boils down to following a simple methodology when refactoring code and utilizing hibernate as the object relational mapping solution.

There seem to be a lot of implementations out there where properties of objects are abstracted or referenced in a language independent properties file. I have been there, seeking the "most flexible" solution using reflection but then thinking maybe i lose something by being too flexible in terms of code mainteance and losing the benefits of being not being in a more pure/complete languge based oo-solution.

As a side note, rather than abstract out object properties or references into a non-oo language xml file, perhaps configuration files can be java classes instead which act upon the objects it needs to map? Maybe eclipse would automatically refactor code more easily or at least catch issues where references are broken(though I admit, there is probably a bunch of things that might have to happen if the database changes anyway but not sure).

Also, I have not read up on the latest hibernate so a simple response might be to read more elsewhere. Anyone got a link?==P.

Thanks for any advice/input in advance.

Take care.

Ken

strong types or strong tests ;)

Funny you should mention that...I was just reading up on the trials and tribulations of unit testing hibernate(DBUnit, something with caveatEmptor, Spring, etc..)

Seen some solutions out there and I could live with that however my questions above are also by determining cost of maintenance as well as catching build problems(which your answer points out and is true whether I use hibernate or not). But I don't use unit tests to catch refactoring issues that I would have otherwise caught in eclipse with the nice red mark you get because a getter/setter no longer exists. Your just suggesting that I use more unit testing to leverage the fact that I can't catch build issues. The downside is that now you have to rely on well-written unit tests to catch it all(not real practical when your on a time budget, etc).

One the theories behind objected-oriented design is that, cost of maintenance over time is less as the design evolves(most don't consider it). Though I lack the experience with hibernate, it looks like there could be an increase of cost of maintenance(how signficant that cost is the point of my email).

I am looking for some wisdom with anyone that has practical experience at an enterprise level with hibernate and how well it is to manage this stuff as changes in their business model are refactored whether or not the database is refactored at all.

Thanks for your input..=P

Sorry...if it helps...im looking for answers like

"Ya, we have 35 business classes using hibernate and have gone through several refactoring cycles and follow this methodology which makes it painless"

OR

"Ya, we have 25-50 business classes using hibernate and we went through a refactoring process changing 10 of them and it was a royal pain in the butt"

OR

"Ya, we use such and such a tool which automatically catches our issues pre-runtime and its not that hard to change the configuration files around as your model changes."

Thanks.

Ken

you should check out H tools and annotations. w/ annotations, you have fewer loc in xml, so there is less type risk. the tools suite allows you to generate domain models from configuration, or vice versa. a change in one means a regeneration of the other, not a change of the other .

i convinced a DB designer last week to put synthetic identifiers on more than 30 tables. this meant changing 30 xml files and regenerating 30 java classes. futhermore, you can also tell the code generator to generate classes w/ interfaces. when you make a mistake refactoring, the mistake is caught by the compiler.