This is a continuation of my Introduction to ASP.NET MVC series.  As I outlined before this is in an effort to write the book and keep blogging, I decided to write/blog the last chapter, Chapter 2.  I am doing this so I can receive feedback on this chapter as early as possible.  Because this chapter, in my opinion, is probably the most critical of the book, it defines the context around ASP.NET MVC and how it differs from ASP.NET Web Forms, as well as giving a historical perspective of the MVC pattern.

In the next several posts we will cover the following parts of Chapter 2 from the book:

• The Model-View-Controller Pattern
• ASP.NET MVC vs. ASP.NET Web Forms
• Installing the Prerequisites
• Your First ASP.NET MVC Project
• The Model
• The View
• The Controller

ASP.NET MVC 1.0 Website Programming: Problem – Design – Solution by Nick Berardi New: $31.49 This item has not yet been released. You may order it now and we will ship it to you when it arrives.

ASP.NET MVC vs. ASP.NET Web Forms

As you have seen, in the previous section, and can probably imagine MVC is going to be an architectural pattern that is going to be around for the foreseeable future, especially on the web.  So it is very important to internalize and understand the major differences between ASP.NET MVC and the older ASP.NET Web Forms.

ASP.NET Web Forms

Starting with the .NET Framework Version 1.0, in January 2002, Web Forms was Microsoft’s first real attempt to provide a first class web application layer that was both robust and flexible enough to meet the demands of the web at that time.  ASP.NET Web Forms has proven to be a mature technology that runs small and large scale websites alike.  Web Forms, was built around the Windows Form construction, where you had a declarative syntax with an event driven model.  This allowed visual designers to take full advantage of the drag and drop, WYSIWYG, interface that they had become accustom to under Windows Forms development in Visual Studio 6.0.  In that they only needed to drop controls onto the ASP.NET page and then wire up the events, as was common in Visual Basic 6.0 development at the time. This made Web Forms a natural choice for Windows Forms developers, because the learning curve was low and the need to understand HTML and many of the web centric technologies almost zero.  Web Forms have many strengths and weaknesses:

Strengths

• Mature technology
• Provides very good RAD development capabilities
• Great WYSIWYG designer support in Visual Studio
• Easy state management
• Rich control libraries from Microsoft and third party vendors
• Abstracts the need to understand HTTP, HTML, CSS, and in some cases JavaScript
• ViewState and PostBack model
• A familiar feel to Windows Forms development

Web Forms has grown so much since 2002 because it has the ability to do great things that are often much harder to accomplish in other frameworks.

Weaknesses

• Display logic coupled with code, through code-behind files
• Harder to unit test application logic, because of the coupled code-behind files
• ViewState and PostBack model
• State management of controls leads to very large and often unnecessary page sizes

Web Forms is not all roses and buttercups, there are some serious setbacks that usually show up when you are trying to optimize your code for scalability, the biggest problems are the ViewState and PostBack model.  ViewState is a way to store the state of the controls, such as data, selections, etc, which is needed to preserve the Windows Form like development habits of the developers.  ViewState was necessary, because the web is a stateless environment meaning that when a request comes in to the server it has no recollection of the previous request.  So in order to give state to a stateless environment you need to communicate the previous state back to the server, in Web Forms this was accomplished using hidden <input /> fields that can become ridiculously large. This increased size becomes apparent when server controls such as GridView are added to the page.  PostBack was another creation to facilitate the Windows Form development feel, it renders JavaScript for every subscribed event, which leaves web developer less control over how the browser communicates with the server.

ASP.NET MVC

ASP.NET was often overlooked as a viable platform for modern highly interactive websites that required a very granular control over the output of the HTML, because of the lack of control over the rendered HTML.  This granularity of control was sacrificed in Web Forms to make if more like Windows Forms development, in other words easier for the drag and drop developers.  This lack of control over the HTML rendering forced developers to move the platforms such as PHP and Ruby on Rails, which offered the level of control they required and the MVC programming model that provided a necessary separation of concerns for their highly complex web applications.

This led Microsoft to announce in the Fall of 2007 that they were going to create a platform based off of the core of ASP.NET that would compete against these other popular MVC web centric platforms.  Microsoft implemented ASP.NET MVC to be a modern web development platform that gives a ‘closer to the metal’ experience to the developers that program with it, by providing full control and testability over the output that is returned to the browser.  This is the main and most important different between Web Forms and MVC, in my opinion.  MVC has many strengths and weaknesses

Strengths

• Provides fine control over rendered HTML
• Cleaner generation of HTML (well as clean as you keep it)
• Clear separation of concerns
• Provides application layer unit testing
• Can support multiple view engines, such as Brail, NHaml, NVelocity, XSLT, etc.
• Easy integration with JavaScript frameworks like jQuery or Yahoo UI frameworks
• Ability to map URLs logically and dynamically, depending on your use
• RESTful interfaces are used by default (this helps out with SEO)
• No ViewState and PostBack model
• Supports all the core ASP.NET features, such as authentication, caching, membership, etc.
• Size of the pages generated typically much smaller because of the lack of the ViewState

Weaknesses

• Not event driven by the framework, so it maybe more difficult for ASP.NET Web Form developers to understand
• Requires the need to understand, at least at the basic level, HTTP, HTML, CSS, and JavaScript
• Third party library support is not as strong
• No direct upgrade path from Web Forms
• No ViewState and PostBack model (makes it more difficult to preserve state)

As you can see the pros and cons of MVC have to be weighed just as much as Web Forms, and MVC is not always the logical choice.

How do I choose?

It’s up to you to decide and you choice needs to be weighted with a number of other factors, such as team and application requirements, when deciding which ASP.NET technology to implement.  I have developed the following worksheet that will hopefully help you decide, when you need to make this decision.

The Worksheet

This worksheet is meant to be a guide for when you are trying to choose between Web Forms and MVC.  The values in the Value column are representations of how easy it would be to accomplish the requirement in either MVC or Web Forms.

The values range from 0 to 30, zero being no effort to implement and 30 requiring a great amount of effort to implement.  If the value is positive then it is an advantage to MVC, if the value is negative then it is an advantage to Web Forms.  For example if the value is, +4, then the requirement is more suited for MVC, and it would take a little work to get it to work as easily in Web Forms.  Alternatively, if the value is, -25, then the requirement is definitely suited for Web Forms, and it would take a lot of work to get the requirement to work with MVC.

So after you make your selection and add up all the values, you should end up with a number representing your project.  Check that number against the table below, and you should have your answer as to which technology, MVC or Web Forms, is best for your project and team.

I want to mention one last thing if you have want to do new development in MVC, but you have to maintain some legacy Web Form pages, you can mix MVC and Web Forms in the same application. You just need to be aware of the differences between the two, and that you probably will not be able to share any of the Web Form front end code with MVC, such as Themes, Master Pages, and User Controls.

As you probably can guess by the name of this book, The Beer House application landed well in to the MVC side of the worksheet.  Which probably doesn’t surprise you if you are reading this book!

Feel free to use the above decision table and modify it for your own teams’ decision process.  The information provided above however should arm you with most of the important information that you need to know when deciding which way your project should go technology wise.

This post is licensed under a different license than the rest of my site. Copyright © Wiley Publishing Inc 2009

About a month and a half ago I announced that I am writing a book, I was really overwhelmed by the amount of support that I received from this announcement.  Both myself and Al are really looking forward to the day when this book ships, and we start receiving real feedback on all our hard work.  However, both of us would like to start receiving feedback as soon as possible, so…

In an effort to write the book and keep blogging, I decided to write/blog the last chapter, Chapter 2.  I am doing this so I can receive feedback on this chapter as early as possible.  Because this chapter, in my opinion, is probably the most critical of the book, it defines the context around ASP.NET MVC and how it differs from ASP.NET Web Forms, as well as giving a historical perspective of the MVC pattern.

In the next several posts we will cover the following parts of Chapter 2 from the book:

• The Model-View-Controller Pattern
• ASP.NET MVC vs. ASP.NET Web Forms
• Installing the Prerequisites
• Your First ASP.NET MVC Project
• The Model
• The View
• The Controller

ASP.NET MVC 1.0 Website Programming: Problem – Design – Solution by Nick Berardi New: $31.49 This item has not yet been released. You may order it now and we will ship it to you when it arrives.

The Model-View-Controller Pattern

The Model-View-Controller architectural pattern has been around since 1978 and was first described by Trygve Reenskaug while working on a programming language called Smalltalk at Xerox PARC.  The implementation was first described in his now famous paper on the subject, titled Applications Programming in Smalltalk-80: How to use Model-View-Controller, published on December 1979, and has been popping its head up in many different ways and forms since the original paper was published.  Reenskaug maintains a page that explains MVC in his own words (http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html), and contains his publications on the subject; it is well worth the read and is only two pages long.

The MVC pattern has been implemented in most every programming language that is in use today, including ColdFusion, Java, JavaScript, Perl, PHP, Python, Ruby, Smalltalk, XML, and of course .NET.  In fact in November, 2002 the W3C, the main international standards body for the World Wide Web, voted to make the MVC pattern part of their XForms specification, which will be integrated directly into the XHTML 2.0 standard.

Reenskaug explains on this site that “The essential purpose of MVC is to bridge the gap between the human user’s mental model and the digital model that exists in the computer.”  As illustrated in Figure 2-1.

Figure 2-1

He goes on to explain that “The ideal MVC solution supports the user illusion of seeing and manipulating the domain information directly.  The structure is useful if the user needs to see the same model element simultaneously in different contexts and/or from different viewpoints.”  This is important because it puts the emphasis not on the application, but how the user perceives the data, the controller and view is only a means to the end of allowing the user to visualize the model in other words.

Reenskaug defines the Model-View-Controller in the following way.

• Model: Represents knowledge.  A model can be in the simplest case a single object in your application, or in a complex case combination of objects.  It should represent the world as seen by the developer for the application that is being developed, in other words your database or domain.
• View: Visual representation of the Model.  It should highlight the certain aspects of the model while minimizing the others where possible.  According to Reenskaug it should act as a presentation filter.  What he describes as a presentation filter is the notation of a contract created between the Model and the View that will provide the parts of the model requested for the presentation by the View.
• Controller: A controller provides a link between the user and the system.  It provides the user with actions that can be taken against the Model, which in other words creates a set of inputs that can be acted upon and represented to the user in one or more ways through a View.

Bringing MVC Down To Earth

The concepts and ideas behind MVC were honestly a little abstract for me when I was first getting started, it took me a while to understand how the Model, View, and Controller where suppose to work together to create an application.  Unfortunately at the time I didn’t have a great example that clearly defined the lines between the different parts of the Model, View, and Controller, so I had to learn the hard way.  Lucky for us Jeff Atwood, of codinghorror.com fame, provided an example that really struck a chord with me.  Figure 2-2 is a visual representation of his example.

Figure 2-2

This example almost perfectly represents MVC in a way that any web developer with only basic knowledge of HTML and CSS can understand.

• Model: The HTML is the “skeleton” or definition of the data to be displayed to the user.
• View: The CSS is the “skin” that gives the HTML a visual presentation.  The CSS can be swapped out to view the original content in a different manor, without altering the underlying Model.  They are relatively, but not completely, independent of each other.
• Controller: The browser is responsible for combining the CSS and HTML, into a final representation that is rendered out to the screen in the form of pixels.  It gathers input from users, but it is restricted to the input defined by the HTML in the form of input, select, textarea, and button DOM objects.

I find this to be an awesome acknowledgement to the success of the Model-View-Controller, because the browser is a natural interface for a computer user that wants to visualize the World Wide Web.  It successfully maps the Mental Model, from Figure 2-1, that a designer envisioned as an interface for the user to the Computer Model, which a developer coded for use on the World Wide Web.  So I hope this helped you visualize MVC in a way that helps you break out and understand the concepts behind the Model, View, and Controller.  If you would like to read Jeff’s full article it is available at http://www.codinghorror.com/blog/archives/001112.html.

For the purpose of this book we are going to define MVC as the following:

• Model: The classes which are used to store and manipulate the state of the database, through our domain objects, combined with some business logic.
• View: The user interface parts, coded in HTML, necessary for rendering the Model to the user.  It may also render the Model as XML or JSON if needed programmatically by JavaScript.
• Controller: The application layer that will accept the input and save that information to the database through our Model.  It will also contain a small amount of business logic necessary for controlling and validating the inputs.  The controller will also decide which view to render, the HTML, XML, or JSON depending on the form that was requested by the browser.

The above definition of MVC for our application, The Beer House, is an almost exact representation of MVC as defined by the ASP.NET MVC team.

This post is licensed under a different license than the rest of my site. Copyright © Wiley Publishing Inc 2009

About a month ago I was experimenting with different ways to optimize my LINQ queries against the IdeaPipe database, in order to improve the read times. I wanted to improve the read times because our new Facebook Application was being launched and I anticipated an increase in our traffic to the server, which is used to host IdeaPipe and the Facebook Application component.

Whenever I am trying to optimize SQL queries I fire up SQL Server Profiler and take a look at how the queries are performing. This helps me identify queries that are taking a longer time to execute and probably need to be looked at or re-thought. One of the queries that I identified as needing improvement was the following LINQ query:

Old Query

from i in source
join xgl in GroupIdeaLinks on i.IdeaId equals xgl.IdeaId into groupLinksGroup
from gl in groupLinksGroup.DefaultIfEmpty()
let visibility = (gl == null ? 'O' : gl.Group.VisibilityPermission)
let groupId = (gl == null ? -1 : gl.GroupId)
where visibility == 'O' || GroupMembers.Count(m => m.GroupId == groupId && m.IsApproved && m.UserId == userId && (visibility == 'G' || (m.RoleId & (int)Role.Manager) == 0)) == 1
select i;

That produced this monster of a SQL statement:

SELECT [t5].[IdeaId], [t5].[CategoryId], [t5].[UserId], [t5].[IsPopular], [t5].[PopularOn], [t5].[Title], [t5].[SafeDescription], [t5].[Description], [t5].[Path], [t5].[Score], [t5].[Rank], [t5].[ExternalLink], [t5].[VideoLink], [t5].[BumpUpCount], [t5].[BumpDownCount], [t5].[TotalBumpCount], [t5].[TotalCommentCount], [t5].[CreatedOn], [t5].[rowversion]
FROM (
    SELECT [t4].[IdeaId], [t4].[CategoryId], [t4].[UserId], [t4].[IsPopular], [t4].[PopularOn], [t4].[Title], [t4].[SafeDescription], [t4].[Description], [t4].[Path], [t4].[Score], [t4].[Rank], [t4].[ExternalLink], [t4].[VideoLink], [t4].[BumpUpCount], [t4].[BumpDownCount], [t4].[TotalBumpCount], [t4].[TotalCommentCount], [t4].[CreatedOn], [t4].[rowversion], [t4].[value],
        (CASE
            WHEN [t4].[test] IS NULL THEN @p1
            ELSE [t4].[GroupId]
         END) AS [value2]
    FROM (
        SELECT [t0].[IdeaId], [t0].[CategoryId], [t0].[UserId], [t0].[IsPopular], [t0].[PopularOn], [t0].[Title], [t0].[SafeDescription], [t0].[Description], [t0].[Path], [t0].[Score], [t0].[Rank], [t0].[ExternalLink], [t0].[VideoLink], [t0].[BumpUpCount], [t0].[BumpDownCount], [t0].[TotalBumpCount], [t0].[TotalCommentCount], [t0].[CreatedOn], [t0].[rowversion], [t2].[test], [t2].[GroupId],
            (CASE
                WHEN [t2].[test] IS NULL THEN @p0
                ELSE CONVERT(NChar(1),[t3].[VisibilityPermission])
             END) AS [value]
        FROM [Ideas].[Ideas] AS [t0]
        LEFT OUTER JOIN (
            SELECT 1 AS [test], [t1].[GroupId], [t1].[IdeaId]
            FROM [Groups].[GroupIdeaLink] AS [t1]
            ) AS [t2] ON [t0].[IdeaId] = [t2].[IdeaId]
        INNER JOIN [Groups].[Groups] AS [t3] ON [t3].[GroupId] = [t2].[GroupId]
        ) AS [t4]
    ) AS [t5]
WHERE (UNICODE([t5].[value]) = @p2) OR (((
    SELECT COUNT(*)
    FROM (
        SELECT
            (CASE
                WHEN ([t6].[GroupId] = [t5].[value2]) AND ([t6].[IsApproved] = 1) AND (([t6].[UserId]) = @p3) AND ((UNICODE([t5].[value]) = @p4) OR (([t6].[RoleId] & @p5) = @p6)) THEN 1
                WHEN NOT (([t6].[GroupId] = [t5].[value2]) AND ([t6].[IsApproved] = 1) AND (([t6].[UserId]) = @p3) AND ((UNICODE([t5].[value]) = @p4) OR (([t6].[RoleId] & @p5) = @p6))) THEN 0
                ELSE NULL
             END) AS [value]
        FROM [Groups].[GroupMembers] AS [t6]
        ) AS [t7]
    WHERE [t7].[value] = 1
    )) = @p7)

So I started playing around with the LINQ statement until I reduced the size of my SQL query significantly. The following is the result of that optimization:

New Query

var groupMembership = (from gm in GroupMembers
                       let visibility = gm.Group.VisibilityPermission
                       where visibility == 'O' || (gm.IsApproved && gm.UserId == userId && (visibility == 'G' || (gm.RoleId & (int)Role.Manager) == 0))
                       select gm.GroupId).Distinct();

from i in Ideas
join xgl in GroupIdeaLinks on i.IdeaId equals xgl.IdeaId into groupLinksGroup
from gl in groupLinksGroup.DefaultIfEmpty()
where gl == null || groupMembership.Contains(gl.GroupId)
select i;

Which outputs the following SQL query:

SELECT [t0].[IdeaId], [t0].[CategoryId], [t0].[UserId], [t0].[IsPopular], [t0].[PopularOn], [t0].[Title], [t0].[SafeDescription], [t0].[Description], [t0].[Path], [t0].[Score], [t0].[Rank], [t0].[ExternalLink], [t0].[VideoLink], [t0].[BumpUpCount], [t0].[BumpDownCount], [t0].[TotalBumpCount], [t0].[TotalCommentCount], [t0].[CreatedOn], [t0].[rowversion]
FROM [Ideas].[Ideas] AS [t0]
LEFT OUTER JOIN (
    SELECT 1 AS [test], [t1].[GroupId], [t1].[IdeaId]
    FROM [Groups].[GroupIdeaLink] AS [t1]
    ) AS [t2] ON [t0].[IdeaId] = [t2].[IdeaId]
WHERE ([t2].[test] IS NULL) OR (EXISTS(
    SELECT NULL AS [EMPTY]
    FROM (
        SELECT DISTINCT [t3].[GroupId]
        FROM [Groups].[GroupMembers] AS [t3]
        INNER JOIN [Groups].[Groups] AS [t4] ON [t4].[GroupId] = [t3].[GroupId]
        WHERE (UNICODE([t4].[VisibilityPermission]) = @p0) OR (([t3].[IsApproved] = 1) AND (([t3].[UserId]) = @p1) AND ((UNICODE([t4].[VisibilityPermission]) = @p2) OR (([t3].[RoleId] & @p3) = @p4)))
        ) AS [t5]
    WHERE [t5].[GroupId] = [t2].[GroupId]
    ))

As you can tell the second query is much more compact and it does the exact same thing as the first query. I was pretty proud of my self and riding high on my genius, until this happened:

Well this didn’t really happen, but you get the point. I quickly came down from my high when I tested the performance of the new query in SQL Server Profiler, and received these results from the two queries:

• OLD QUERY (Reads 130, Durration 5)
• NEW QUERY (Reads 218, Durration 28)

That is right my optimization increased the number of times SQL has to read the table by 68% and time it takes to execute by 460%. So I reversed all my changes and learned a lesson on how not to optimize a LINQ statement.

The moral of the story is you probably don’t need to optimize your SQL query through LINQ, just keep it simple and optimize your LINQ statement and leave the rest up to the professionals at Microsoft who created the LINQ to SQL expression query generator.