Tutorial 6: Showing the Results in a View

The domain’s been created, the data access mechanism is in place, the controller has been developed...the only thing remaining is to populate the development database with some test data and to throw together a little HTML to pull it all together. By the time you get here, the view is but a minor afterthought.

In this tutorial, we’ll be using ASP.NET MVC pages to create the views. But ASP.NET MVC is so extensible that you can use a variety of mechanisms for developing your view. The MVC Contrib documentation discusses four options at http://www.codeplex.com/MVCContrib/Wiki/View.aspx?title=Documentation. To illustrate, you can find an example of using the Spark View Engine with S#arp Architecture at http://groups.google.com/group/sharp-architecture/web/spark-view-engine.

With respect to unit testing, there are a variety of opinions on how much of the view layer should be unit tested. On one hand, the view layer changes so frequently that a lot of maintenance is required to manage tightly coupled view-oriented unit tests via a tool such as NUnitAsp (http://nunitasp.sourceforge.net) or Selenium (http://selenium.openqa.org). On the other hand, it’s not a bad idea to create web "smoke tests" to at least make sure the stated URL isn’t blatantly breaking. For an example of a web smoke test, see http://geekswithblogs.net/Billy/archive/2006/05/10/77820.aspx. There are even tools for unit testing your JavaScript... the options never end!

For this example, we’ll get right to the heart of the matter and create the view:

  1. Go to Northwind.Web/Views and add a new directory called StaffMembers. The name of this folder needs to be the first part of the name of the StaffMembersController controller class that it is associated with; consequently, it’s very important that it’s named this way.


  2. Under the StaffMembers directory, add a new Web Content Form (or MVC Content Form if you have ASP.NET MVC installed) called ListStaffMembersMatchingFilter.aspx and select Site.Master (in /Views/Shared) as the master page. The ASPX should be modified to reflect the following:

    <%@ Page Title="" Language="C#" AutoEventWireup="true"
    MasterPageFile="~/Views/Shared/Site.Master"
    Inherits="ViewPage<IEnumerable<StaffMember>>" %>
<%@ Import Namespace="Northwind.Core" %>

<asp:Content ContentPlaceHolderID="MainContentPlaceHolder" runat="server">
    <p>Matching Staff Members:</p>
    <ul>
        <%
        foreach (StaffMember staffMember in ViewData.Model) { %>
         <li><%= staffMember.EmployeeNumber %></li><%
        }
        %>
    </ul>
</asp:Content>

    If you don’t have ASP.NET MVC installed and created a Web Content Form, simply delete the code-behind and corresponding designer file associated with view. No more code-behind... that’s a good thing!

    The page could have inherited from ViewPage<List<StaffMember>>, since that’s what the controller is giving it, but inheriting from ViewPage<IEnumerable<StaffMember>> makes it a bit more flexible and reusable by a variety of controllers which may not always have a List<StaffMember> available.


  3. Populate the table with test data to support passing the test.

          USE Northwind
      GO 
      INSERT INTO StaffMembers VALUES ('thistest_Filter', 'Mike', 'Park') 
      INSERT INTO StaffMembers VALUES ('ABC123', '_test_FiLtEr_', 'Vance') 
      INSERT INTO StaffMembers VALUES ('GHI789', 'Lynette', 'Knackstedt') 
      INSERT INTO StaffMembers VALUES ('DEF456', 'Gerry', 'Lundquistest_filtER')


  4. Give it a whirl! Hit F5 and change the URL to reflect http://localhost:####/StaffMembers/ListStaffMembersMatching?filter=test_Filter. You should be presented with the same three users that your unit test returned from the SQLite database. This is completely incidental since we happened to populate our Northwind database with the exact same data that the unit test populated SQLite with. Note that there is absolutely no need to keep the live database in synch with the data used by the unit tests with SQLite. This is a terrific benefit of using an in-memory SQLite database for unit testing data access methods and avoids developing fragile tests which start breaking as soon as the data within the database changes. Assume that our unit test instead depended on the Northwind database; if the test data gets out of synch with the tests, then the tests start breaking. And once they start breaking, and aren’t fixed quickly, then developers stop running them. So any test that depends on live data in a persistent database should be considered a fragile test and avoided unless absolutely necessary.



Index | Back: Retrieving Results via a Custom DAO | Next: Conclusion