CODEWITHSUNDEEP
asp.netasp.net-mvc
foop
foop

Reputation: 523

MVC vs WebForms in my production environment

Over the past couple weeks I've been examining MVC 4.0 and am trying to see whether or not to make the switch from web forms to MVC.

My current production environment is: 1) One master database, with 3 separate asp.net web form applications (a scheduler, sales reporting, central administration) that communicate with it 2) This master database does not contain the appropriate foreign keys, uses a lot of stored procedures for current applications, the structure could probably use some re-designing as well but its' what I've inherited with some legacy systems & code.

As I started created a prototype for an improved sales reporting application I started running into issues where I had to continually make modifications to the database using the migration tool in Visual Studio. I found that the relationship between tables were not correctly established, so it's been more challenging using the entity framework.

I am by no means a MVC expert and entity framework expert, but I've started to question whether I should jump into MVC with my existing situation. What probably scares me the most is the amount of database changes that I've had to make in my test environment to just enable the proper models for my controller and views. With me making these changes, I feel that the other 3 web form applications will have to be properly re-tested which we don't have the resources for. We cannot afford anything to go wrong in the master database or web form apps because those are client facing.

I don't mind the learning curve of MVC, I do find it quite interesting, my manager does not care what I use, and isn't opposed to me learning an extension of asp.net. I suppose there is a timeline in place, but not concrete.

I'm just reaching out to others who may have faced this similar scenario. Are my concerns valid? Should I just stick with another web form application or should I push forward into the MVC world?

Upvotes: 2

Views: 684

Answers (1)

Chris Woolum
Chris Woolum

Reputation: 2914

Depends on how well separated the layers of your application are. If you have solid service layer that handles all of your data access and just passes domain objects back and forth, your conversion to MVC is actually not that bad. Its very feasible to have an MVC front end on a standard ADO.Net back end.

Based on the structure of your database, trying to use EF is going to be difficult unless all the proper constraints are put into place. EF won't even work unless your database is set up properly.

If you want to move to MVC I would recommend doing this in stages.

  1. Separate your UI layer from your service layer if it is not already.
  2. Convert your UI layer to MVC.
  3. When you are happy with the UI, you can start making database changes and convert your Data Access layer to EF.

While you are converting your UI to MVC, create models to replicate your database tables and just pass those to the UI instead of what you are directly pulling back. That way when you convert to EF, you will already have the correct models in place and your UI layer will be unaffected by the changes

Upvotes: 3

Related Questions