Disadvantages of the ASP.NET MVC Framework

(1) Writing View Contents the Old ASP-Like Way

Let’s first take a look at a piece of the MVC-styled view code, as follows:

<ul> <% foreach (Article article in this.GetArticles())

{ %>

<li>

<img src="<%= "http://img.dummy.net/" + article.ImagePath %>"

alt="<%= article.Title %>" />

</li>

<% } %>

</ul>

As you may have noticed above, it uses an inline mode, foreach, to render the .aspx page’s contents. Indeed, code generated in the above mode is spotless whether in the case of cleanness or from the angle of self definition. But……yes, as you have seen, it’s the original ASP mode, just switched to another term—the ASP.NET MVC-styled template! Isn't it ironic? Yet, this is indeed the fact.

Since a flock of developers are now ready to embrace ASP.NET MVC without  hesitation, are they also ready to deal with the old-style inline mode? Due to the features of ASP.NET MVC (mainly a ViewData transferred from the Controller to the View), the true ASP.NET MVC template syntax requires a plus CAST, such as the following (of course, you can also use the strong-typed ViewData supported by ASP.NET MVC, which can help to avoid such a cast operation):

<ul> <% foreach (Article article in (ViewData["Articles"] as List<Article>))

{ %>

<li>

<img src="<%= "http://img.dummy.net/" + article.ImagePath %>"

alt="<%= article.Title %>" />

</li>

<% } %>

</ul>

Now I wonder: is this progress merely from the viewpoint of the View writing? Does ASP.NET MVC go back to the ASP years (of course it adds some HTML helpers)?

In fact, the crucial characteristic of ASP.NET MVC lies in the isolation of M-V-C, the invocation mode of the business logic, and the new-styled URL Routing drive mode, rather than the template mode. So it’s not true to say the View tier of MVC is more clear than that in ASP.NET Web Forms, because we can also write in the mode quite similar to ASP.NET MVC in an ASP.NET .aspx web form.

The Second Disadvantage

(2) Unit Test Makes the Learning Curve Steeper

Now, from many authorities, ASP.NET MVC is boosted to be superior to ASP.NET Web Forms in terms of test-driven development. Certainly, the MVC model helps to achieve separation of controller and view issues (in the classic ASP.NET Web Forms, the two are in one .aspx page) for the main purpose of simplifying  testing. However, it increases the learning curve for those without a TDD (i.e. Test-Driven Development) background.

On the whole, the main causes that increase the steepness of the learning curve with ASP.NET MVC include at least two aspects:

(a) Piles of new basic concepts, such as ViewData, TempData, RouteCollection, Controller Action, Linq to SQL, Lambda Expression, Custom Route, and HTML Helpers, all of which constitute the bindings that tie the View, Controller, and Model. It is not until you have to grasped these entirely new concepts that you can start to write applications using ASP.NET MVC. For reference to these new concepts, I suggest you to visit Stephen Walther’s blog articles at http://weblogs.asp.net/stephenwalther/default.aspx.

(b) Another important stumbling block for newbies to learning ASP.NET MVC is the TDD (i.e. Test-Driven Development). TDD is an evolutionary approach to development which combines test-first development, where you write a test before you write just enough production code to fulfill that test, and refactoring. Test-Driven Development is related to the test-first programming concepts of Extreme Programming, begun in the late 20th century.

In the modern software development field, TDD becomes one of the standard software developing patterns and is welcomed by developers from all over the world. In fact, in the case of ASP.NET Web Forms, there is also TDD, but it’s more difficult to perform compared with the ASP.NET MVC solution.

Therefore, to accept ASP.NET MVC means to accept TDD. And for this, you’d better have some experience with the .NET platform-based Mock frameworks (such as Moq , Rhino Mocks , Typemock Isolator ) and Unit Test frameworks (such as Visual Studio Unit Test, NUnit , xUnit.NET ).

To explore the puzzle with respect to MVC, I’ll show you some examples. First, let’s take a look at the simplest test method (herein "Index") that the system automatically generates:

public class HomeControllerTest{

[TestMethod]

public void Index()

{

// Setup

HomeController controller = new HomeController();

// Execute

ViewResult result = controller.Index() as ViewResult;

// Verify

ViewDataDictionary viewData = result.ViewData;

Assert.AreEqual("Home Page", viewData["Title"]);

Assert.AreEqual("Welcome to ASP.NET MVC!", viewData["Message"]);

}

In this simplest case, we can only use the built-in Visual Studio Unit Test tool to finish the test method. Because, as the controller action method Index() indicates, there are only the two simple ViewData related strings to be transferred to the view "Index," with the release of ASP.NET MVC Preview 4 (it allows the controller action method to return an "ActionResult" as the executing result of the method, which permits postponing the execution of the result), there’s no need to make Mock objects in this simple case—only with the help of the static class Assert can the test task be performed.

Next, let’s examine a rather complex case (you can refer to it in the related downloadable source code with this article), under which we will resort to a third-party Mock framework, Moq, to accomplish the test. By the way, in the attached sample project  named "MVCeProduct" I’ve successfully tested the Action methods: Category(int id), New(), Create(), Edit(int id), and Update(int id). For brevity, I will only introduce the unit test process for the first action method, namely "Category."

Okay, to gain a clearer understanding we’ll first look at the source code of the controller (in our case named "ProductsController") action method, as follows:

//…… (omitted)

using System.Web.Mvc;

using System.Linq;

using System.Web.Routing;

using MvcApplication.Models;

namespace MvcApplication.Controllers

{

public class ProductsController : Controller

{

NorthwindRepository repository;

public ProductsController()

: this(new NorthwindRepository(new eProductDataContext()))

{ }

public ProductsController(NorthwindRepository context)

{

this.repository = context;

}

public ActionResult Category(int id)

{

Category category = repository.Categories.SingleOrDefault(c => c.CategoryID == id);

ViewData["CategoryName"] = category.CategoryName;

return View("List", category);

}

First of all, we’ve defined a private property repository of the public class NorthwindRepository. To create a public class, NorthwindRepository, is to simplify the controller action methods programming, since only using the Model class (in this case "eProductDataContext") automatically generated by the Linq to SQL technique by the system is, in some cases, pretty fussy and even difficult to get through.

It’s just the complex private member that leads to trouble in unit-testing the action methods; this kind of case is very common in practical scenarios. For this, we can still find a solution—fall back upon Moq, the .NET platform-based Mock Object framework, to overcome the difficulty.

In the first line of code in the Category method, an instance of the Category class is created by retrieving the Model component (the lambda expressions are a MUST HAVE in similar cases like this). Since we will dispatch the task of judging whether the instance will be created successfully or not to the unit test, we do not make the judgment. Next, according to the inquired result we assign the related values to the Dictionary object named "ViewData." At last, the final line switches the current View to another View—List, and passes in the required Category instance.

Thus, in this case, the controller will render the contents of the view List using the passed ViewData data (less often) and the data from the Model component (more often).

Category Method

Next, let’s take a look at the unit test related to the Category method, as follows:

//…… (omitted)

using Microsoft.VisualStudio.TestTools.UnitTesting;

using MvcApplication.Controllers;

using MvcApplication.Models;

using System.Web.Mvc;

using System.Web.Routing;

using Moq;

namespace MvcApplicationTest

{

[TestClass()]

public class ProductsControllerTest

{

[TestMethod]

public void Category()

{

var categories = new List<Category>();

categories.Add(new Category { CategoryID=123,CategoryName = "Roomba"});

var repository = new Mock<NorthwindRepository>();

repository.Expect(r => r.Categories).Returns(categories.AsQueryable());

var controller = new ProductsController(repository.Object);

var result = controller.Category(123) as ViewResult;

Assert.IsNotNull(result, "Expected the result to be a render view result");

Assert.AreEqual("Roomba", result.ViewData["CategoryName"]);

var viewData = result.ViewData.Model as Category ;

Assert.AreEqual(123, viewData.CategoryID);

Assert.AreEqual("Roomba", viewData.CategoryName);

}

First, you should have noticed here that we have not only referred to the built-in namespace Microsoft.VisualStudio.TestTools.UnitTesting, but also to Moq. The current version of Moq is 2.5.3. Although this framework is simple, due to introducing the new lambda expression, Moq can provide a clear grammar form to describe the expectation, parameter constrains, and returned values. For detailed information, you can refer to this blog .

In the unit test programming, when complex objects are used (in this case the NorthwindRepository typed variable) or difficult to implement for the time being, we can rest on the Mock object to simulate the target object, which is properly consistent with the basic idea of TDD. Here, we will use the Moq class provided by the Moq framework to mock the NorthwindRepository class, as follows:

var repository = new Mock<NorthwindRepository>();

Next, we use the following sentence to set up the expectation of the set of the Category objects:

repository.Expect(r => r.Categories).Returns(categories.AsQueryable());

Then, we create an instance of the ProductsController class and pass in the repository.Object. Note here that the repository represents the mock object, while the repository.Object refers to the target object that the mock object mocks.

Since the last several Asserts are easy to follow, we won't dwell on them.

Well, how are you feeling now? It’s not as easy as you imagine if you do not possess the abundant and solid basic TDD knowledge and all the other required programming skills, isn’t it? In fact, there are many more parts that need to be tested: the Route, the ViewData, the HTTPContext-related items, etc.

Another fact is that for now the MVC framework has not even published its normal release version, and therefore, no detailed help documents can be found (so most of the reference material can only be hunted down from blogs).

Anyway, the ASP.NET MVC is a new and alternate architecture for your ASP.NET applications, with many new features completed and many more to be added.

Conclusion

In this article series, we’ve made a rough comparison between ASP.NET MVC and ASP.NET Web Forms in terms of constructing ASP.NET web applications. As is clearly claimed in most places by Microsoft specialists, the new ASP.NET MVC will act as merely an optional web project type for ASP.NET applications.

Although the ASP.NET MVC framework provides a more structured model that enforces a clear separation of concerns within applications, and makes it easier to unit test ASP.NET applications, as well as many other more good characteristics, it raises the learning threshold for most beginners without enough required fundamentals (JavaScript programming, ORM concepts, Linq to SQL, C# Lambda expression, Unit Test experience in TDD, etc.). Moreover, the ASP.NET MVC framework will probably catch up in the UI control department, but most likely it will never be as easy to get started with as Web Forms, where massive amounts of functionality are just a drag and drop away.

All in all, in the face of practical requirements you should consider carefully whether to implement the web application by using either the ASP.NET MVC framework or the ASP.NET Web Forms model. The MVC framework will not replace the Web Forms model; you can use either framework for Web applications. So, before deciding to use the MVC framework or the Web Forms model for a specific web site, weigh the pros and cons of each approach prudently and carefully.

It also helps provide more control over the URLs you publish in your applications, and can optionally provide more control over the HTML that is emitted from them.

-DOWNLOAD SOURCE-

References

Here's a list of other interesting posts you might want to read:

The REST-like Aspect of MVC Framework

ASP.NET MVC Framework: An early look

MVC, REST, and the Alternative ASP.NET Framework

ASP.NET MVC framework - ready or not

ASP.NET MVC quick starts