What benefits can I get upgrading my ASP.NET (Webform) + DAL(EF) + Repository + BLL structure to MVC?

Question

I'm in the process of defining an approach that may best fit our needs for a big web application development. For now, I'm thinking going with an ASP.NET Architecture with a DAL using Entity Framework, a Repository concept to not access DAL directly from BLL and a BLL that call the repository and make every manipulations necessary to prepare data to push in a presentation layer (.aspx files).

I don't plan to use ASP.Net controls and prefer to keep things simple and lightweight using plain html, jQuery UI controls and do most of the server calls with jQuery Ajax. Sometimes, when needed, I plan to use handlers (.ashx) to call BLL methods that will return JSON or HTML to client for dynamic stuff.

My solution also has a test project that Mock the Repository with in-memory data to not repose on database for testing BLL methods...

It may be usefull to add that we will build a big application over this architecture with hundreds of tables and store procedures with a lot of reading and writing to database.

My question is, having this architecture in mind, Is there any evident advantages that I can obtain by using an MVC3 project instead of the described architecture base on Webform? Do you see any problem in this architecture that may cause us problem during the next steps of development?

I know the MVC pattern for using it in others projects with Django... but the Microsoft MVC implementation look so much more complex and verbose than Django MVC and it's why I'm hesitating (or waiting for a little push?) right now before jumping into it... We are in a real project with deadlines and don't want to slow the development process without any real benefits.

Answer 1

In my opinion, I would go with MVC. There's a lot of "nice to have" reasons. Model based views, attribute driven authentication, routing control, etc.. MVC will allow you to more cleanly separate the UI from the code layer too. My biggest complaint with ASP.net web-forms is the page event life-cycle especially when used with Master pages and controls. It is a real pain to get everything to render correctly. Lately, in my MVC projects i'll render out a view, which is tied to a model, and then subsequent updates use jQuery to make ajax calls and only update the page where it's needed.

I"ve only had experience with asp.net MVC, no other MVC frameworks, but it's actually much easier to deal with than it may seem. As long as you have some sort of "View Models" which encompass the data needed for a view, getting it on the page is very straightforward. Once you embrace the "simplicity" of MVC, no setting values based on properties in the codebehind, foreach loops on the view, and simple model bound partial views, it's actually a very nice experience.

There's a bit of a learning curve though to get away from asp.net tendencies, and it'll force you to add "layers" to the app to keep things organized, but i think it's the way to go. You can definitely apply the same concepts to WebForms, but again, the defining argument for me is the page events, i do not miss them at all..

The only slowness will come with learning what works for you guys. Once you get a handle on it, it'll be quick clean development, and if you go the right direction, you could end up with a well defined service layer. (obviously the same can be said with webforms, but you get full Clientside control with MVC (no viewstate or wacky control names)). I totally recommend moving away from webForms.