I’ve have quite small asp.net MVC 2 application to maintain/extend. Currently it uses hand written stored procedures + application code for doing data access. Basically what it does is that it loads data and wraps it to POCOs.
Current implementation is tedious to maintain. Especially when I have to add new property – not to mention adding new class/table for doing CRUD. Application has separate caching that is also hard to maintain – and it has led to a few defects. I would love to get rid off that also.
I ‘ve started to thinking about switching to some ORM tool like NHibernate or Entity Framework.
I have very limited experience when it comes to ORM or data access in general. What are the best practices in this situation? What should I take in consideration before jumping to NHibernate/Entity? And what about the downsides?
“Best practice” is one of my least favourite words – it’s often used to assign more importance to an opinion than it really merits…
Having said that…
First, choose your database access strategy; ORM is the current de-facto industry standard, and you’ve identified the front runners; see this thread for a comparison.
Different database access methodologies trade off different things. The one your app currently uses provides a lot of detailed control over the queries and the way they are mapped to your domain – but at the expense of a lot of hand coding. It’s likely to provide the best performance, and the most flexibility; some would argue it’s the easiest to maintain because there’s no “magic” for developers to get their heads round.
ORM solutions trade performance and control for shorter development and (some argue) easier maintenance. There’s a learning curve, and the intermediate layer of “magic” can make some problems harder to identify – the classic anti-pattern with ORM is “loading the entire database into memory”, but performance issues can also be tricky to debug. On the other hand, you reduce the overall amount of code, and make simple CRUD operations far easier to build. Developers with experience in ORM will find it easier to maintain; developers who are new to ORM will have to learn the framework.
In general, I think the industry is moving to ORM for applications that don’t have extreme performance requirements; it’s becoming mainstream, and most developers we interview these days have experience with ORM. However, the learning curve can be quite steep, and there’s a definite chicken and egg – which ORM do you choose without having experience of them all? FWIW, I think Steven Lacy’s answer is on the money there…
What you’re proposing is basically a refactoring. I’d recommend a process along the following lines:
I would put at least as much effort into creating the tests as in the refactoring itself – and I would resist the urge to add new features until you’ve replaced the current implementation.
Make sure your tests include performance and scalability testing.