views:

275

answers:

2

I am starting out on a project that will involve ASP.NET MVC using a legacy ODBC 2.0 compliant database. The goal is to replace current system functionality with a web front end over a period of maybe a year then swap out the backend with SQL Server.

The plan would be to code against SQL server then insert some shim into the repository classes to use ODBC instead. Is it even feasible to do this ? Entity Framework doesn't have built in support for ODBC.

Any thoughts or advice would be appreciated.

+1  A: 

There's nothing to stop you writing your own data access layer, to query the ODBC Database. You could also make your own entity layer so that the MVC model can populate your entities using the data layer, and return these objects to the controller.

Basically, have a data access and entities layer under your mvc app, then you can replace these entities, with entity framework, or nhibernate entities, at a later date.

This way of doing it means that your MVC app doesn't need to know what database it is using, it also means that you should have an easy time when you switch an entity later.

Mark Dickinson
A: 

I personally use NHibernate with MVC. Originally I picked it up because our database doesn't support EF but enjoy it enough that even if we moved to SQL Server I'd keep NHibernate.

The learning curve is kinda weird. It is definitely steep to become an expert, but it is interesting in that it is pretty organic to let it handle more and more of the work for you as you get comfortable with certain layers.

So for your case NHibernate probably supports your database, can be used as a simple data access layer (just returning DTOs), provides a database agnostic interface and can support SQL Server when the time comes. If you end up wanting more out of NHibernate it is there when the time comes.

eyston
Would you say that nhibernate was less work (i.e. cost to the customer) than coding data access and entity layers and swapping them out with EF ?
Andiih