Question

I have a small application developed in ASP.NET 2.0 WebForms. For learning purpose, I am thinking to convert this application to MVC 3 + Entity Framework. Below is the simplest example to simulate my application. Nothing fancy.

Application Layout:

(image should read “input fields” and not “files”)

Architecture:

Key points:

1. Methods in Service layer is using ADO.NET SqlCommand ExecuteReader method to execute stored procedures

2. Most of the manipulation etc. logic is done in stored procedures. Hardly any manipulation of data in Service layer

Now I want to convert this application to MVC.

Questions:

1. What benefit do I get (technically) if I convert this application into MVC + Entity Framework?

2. How do I go about it?

3. I have looked at some basic MVC3 tutorials but they all talk about EF code-first, which I don’t think will fit in my case since I want to use the existing stored procedures. Is that correct?

Note: I want to use the existing stored procedures. Say I don’t have control on DB structure changes.

Update 1:

1. There isn’t a single inline query in my application. Even the smallest little query is a stored procedure. Tons of them.

2. Using SQL Server and almost nil chances of changing to any other DBS.

Update 2:

My webforms application is 99% complete and can go live anytime but due to some business hurdles it hasn’t. In mean while I thought if I can convert (i.e. develop) this to MVC, I will learn plus if it works out can go live (my first MVC) instead of the webforms one.

Answer 1

Before answering the specific questions I’ll point out that you should probably seperate the choices into 2:

1. Converting the presentation layer to use MVC instead of WebForms.
2. Converting the data layer to use EF instead of ADO.NET.

Now for your questions

1. Benefits of MVC include better control over HTML, better testability, etc. Benefits of EF include abstracting away DB-specific things (you could theoretically replace SQL Server with MySQL, assuming an appropriate MySQL provider), LINQ support, etc. Of course there are also costs to such a transition.
2. Divide and conquer. As stated earlier you don’t have to do everything at once. Start with the presentation layer and convert it to MVC. Remember that you can have mixed WebForms and MVC applications so you don’t have to transition all your pages at the same time. Then convert your data layer to EF. Or start in the reverse order, whatever makes sense for your project.
3. [Not an expert in this topic] if you rely heavily on SPs than consider traditional EF. If you have only a few SPs then you could consider code first + handling the SPs with DataSets (potentially wrapped in custom built classes) to make everything work, though that might get complicated. As before, you don’t have to move to EF if the cost is too high.