I'm toying with the idea of phasing in an ORM into an application I support. The app is not very structured with no unit tests. So any change will be risky. I'm obviously concerned that I've got a good enough reason to change. The idea is that there will be less boiler plate code for data access and there for greater productivity.
Do this ring true with your experiences?
Is it possible or even a good idea to phase it in?
What are the downsides of an ORM?
Well.
The rule for refactoring is. Do unit tests.
So maybe first you should place some unittests at least for the core/major things.
The ORM should be designed for decreasing boilerplate code. The time/trouble vs. ROI to be enterprisy is up to you to estimate :)
I heard that TypeMock is often being used to refactor legacy code.
@svrist and @FantaMango77
Thanks for your input. I understand that unit tests are a good idea. The legacy and architecture of this application means that unit testing is difficult. This is why I wish to phase good practise in.
Unfortunately a complete rewrite is not an option.
I would strongly recommend getting a copy of Michael Feather's book Working Effectively With Legacy Code (by "Legacy Code" Feathers means any system that isn't adequately covered by unit tests). It is full of good ideas which should help you with your refactoring and phasing in of best practices.
Sure, you could phase in the introduction of an ORM, initially using it for accessing some subset of your domain model. And yes, I have found that use of an ORM speeds up development time - this is one of the key benefits and I certainly don't miss the days when I used to laboriously hand-craft data access layers.
Downsides of ORM - from experience, there is inevitably a bit of a learning curve in getting to grips with the concepts, configuration and idiosyncracies of the chosen ORM solution.
Edit: corrected author's name
I seriously think introducing ORM into a legacy application is calling for trouble (and might be the same amount of trouble as a complete rewrite).
Other than that, ORM is a great way to go, and should definitely by considered.
Unless your code is already architectured to allow for "hot swapping" of your model layer backend, changing it in any way will always be extremely risky.
Trying to build a safety net of unit tests on poorly architected code isn't going to guarantee success, only make you feel safer about changing it.
So, unless you have a strong business case for taking on the risks involved it's probably best to leave well enough alone.
My 2 cents
I work on a large ASP.net application where we recently started to use NHibernate. We moved a large number of domain objects that we had been persisting manually to Sql Server over to NHibernate instead. It simplified things quite a bit and made it much easier to change things over time. We're glad we made the changes and are using NHibernate where appropriate for a lot of our new work.
The "Robert C Martin" book, which was actually written by Michael Feathers ("Uncle Bob" is, it seems, a brand name these days!) is a must.
It's near-impossible - not to mention insanely time-consuming - to put unit tests into an application not developed with them. The code just won't be amenable.
But that's not a problem. Refactoring is about changing design without changing function (I hope I haven't corrupted the meaning too badly there) so you can work in a much broader fashion.
Start out with big chunks. Set up a repeatable execution, and capture what happens as the expected result for subsequent executions. Now you have your app, or part of it at least, under test. Not a very good or comprehensive test, sure, but it's a start and things can only get better from there.
Now you can start to refactor. You want to start extracting your data access code so that it can be replaced with ORM functionality without disturbing too much. Test often: with legacy apps you'll be surprised what breaks; cohesion and coupling are seldom what they might be.
I'd also consider looking at Martin Fowler's Refactoring, which is, obviously enough, the definitive work on the process.