Opensource .NET tools crash course

The first will be a three-day crash course on tools and practices aimed at .NET developers that want to learn about Alt.NET tools and Java developers that are migrating to .NET and looking for good equivalents to the tools that they are used to working with. The course gives an overview of the most popular opensource .net tools and introduces modern development practices that these tools promote, such as test driven development, continuous integration, dependency injection, object-relational mapping and web development using the model-view-controller pattern.

Learn how to:

• Implement TDD in .NET using NUnit, MBUnit, Rhino Mocks and FitNesse
• Utilise Aspect oriented programming and Dependency Injection using Castle Windsor
• Efficiently build Web applications using the MVC pattern in Monorail and utilising Monorail and Script# for Ajax and test them using Selenium Remote Console.
• Manage persistence easily using ORM tools such as ActiveRecord and NHibernate
• Introduce continuous integration in your projects using CruiseControl.NET and CI Factory

See the full programme.

Agile Web Development with the Castle Framework

The second one is a two-day course on Agile Web Development using the Castle project, teaching the basics of the Castle Framework and helping people develop a solid understanding of its benefits. Over the course of the two days, attendees will create a simple but complete web application using agile Web development practices such as Inversion of Control, Dependency Injection, Aspect Oriented Programming, Object/Relational Mapping and applying the Model-View-Controller pattern.

Learn how to

• Apply agile web development practices like MVC and dependency injection
• Use ActiveRecord to manage the object-relational mapping and the database layer
• Use the Monorail MVC engine to create web applications that are easy to maintain and test
• Explain the basics of Monorail views, layouts, rescues
• Use the NVelocity view engine to build web UIs for Monorail
• Apply Windsor Microkernel to configure and wire application components
• Unit test the data access layer with Castle
• Unit test web controllers
• Describe how Castle components come together to help us develop web applications easier
• Explain why this approach is much more effective than ASP.NET
• Apply best practices, common pitfalls, and tips and tricks for Castle Web development

See the full programme.

Downloads

• PPT slides
• Source code for the SuperPowers app (drag & drop, scriptaculous and prototype effects demo)
• Source code for the JSonDemo app (comparing the three options for ajax with monorail; requires castle trunk DLLs)

Links with more details on the stuff from our talk

• Hammett’s post about Generating JS commands from actions (option #1 from the PPT). For all available functions in $page helper, see the source code of PrototypeGenerator.cs and PrototypeElementGenerator.cs classes.
• Hammett’s post on JSON return binders (option #3 from the PPT)
• Video , links and slides from my earlier talk on agile web development with Castle and Monorail
• Castle-related articles on this web site including the demo app that explains how to develop monorail controllers and how to unit test them.

Some general links

• Monorail web site
• Hammett’s blog and Ayende’s blog are excellent resources for all stuff about Castle.
• Prototype JS library docs
• Scriptaculous JS library docs

For those of you that have just joined this tutorial, this is the fourth iteration of the EvilLink web application, that I am building as a way to demonstrate features of the Castle Project application framework and to present some of the best practices for web application development using the Castle Project. Previous articles in this tutorials are:

• ActiveRecord basics and unit testing
• Monorail basics
• Saving time and effort with advanced Monorail features

So far, we have developed a skeleton of the web application that has user operations and link management functionality. Now we write some unit tests for the controllers.

A quick note before we begin. If you are in UK this week, you might want to come to the free session on developing Ajax applications with Monorail that will take place on Thursday (12/06) afternoon at Skills Matter offices in London. This will give us a chance to discuss any questions about this application as well face to face.

Isolating controllers

The first thing we need to do in order to make our controllers unit testable is to isolate them from any external dependencies, including the System.Web.Http objects. Most of the code that would normally be bound to those objects is handled by Monorail anyway. The only place where System.Web objects are used directly is in the UserContext session wrapper. So let’s replace the UserContext object with an interface and a default implementation. Then we can provide a dummy or mock implementation for unit testing.

using System.Web;
using EvilLink.Database;
namespace EvilLink.Controllers
{
    public interface IUserContext {
        int? CurrentUserId { get; set;}
        User CurrentUser { get; }
    }
    public class WebUserContext:IUserContext 
    {
        public int? CurrentUserId
        {
            get
            { 
              return System.Web.HttpContext.Current.Session["currentUserId"]
               as int?; 
            }
            set
            { 
              System.Web.HttpContext.Current.Session["currentUserId"] = value;
            }
        }
        public User CurrentUser
        {
            get { return User.Find(CurrentUserId); }
        }
    }
}

Now we have to propagate this change to the controllers. Change the field type to IUserContext and create two constructors. The no-parameter constructor will automatically set the default implementation so that our application continues to work as before, but we can also set the context from the outside using the constructor with a parameter.

public class UserOpsController : SmartDispatcherController
{
    private IUserContext context;        
    public UserOpsController(){
        context=new WebUserContext();
    }
    public UserOpsController(IUserContext ctx)
    {
        context = ctx;
    }

This is how we would mock out any external services that controllers may be connecting to or other stuff that prevents unit testing. At the moment, the controllers are still tied to the default implementation with a compile-time dependency. In the next article of this tutorial we look into better ways to handle that, using the Windsor dependency injection container.

Completely detaching from the real Web

Now create a new project in the solution, called EvilLink.Controllers.Test. Add references to Castle.ActiveRecord, Castle.Monorail.Framework, Castle.Monorail.TestSupport, NHibernate and nunit.framework DLLs. Also add references to EvilLink.Controllers, EvilLink.Database and EvilLink.Database.Test projects that we have developed so far. This new project will host our controller unit tests.

The Castle.Monorail.TestSupport library has almost all the support we need to unit test controllers. It provides us with a mock HTTP environment implementation that allows controllers to execute and be inspected in the code. Class BaseControllerTest does all the heavy lifting, we just need to subclass it and call PrepareController to initialize the controller. Then we can execute any of the controller methods directly and verify the effects on the domain or check controller properties to verify messages or objects prepared for rendering. All subclasses of SmartDispatcherController have a public Context property that allows us to inspect the Rails engine context as well.

There is just one slight problem with the BaseControllerTest. All its interesting methods are protected, so the test class has to subclass BaseControllerTest. It would be ideal to reuse the unit testing support for the data access layer that we developed in the first article, but C# does not support multiple inheritance. A workaround for that is to extend BaseControllerTest once, expose appropriate methods as public, and then embed that into another test class that initialises the data access system. Here is MRTestBase class that provides all the functionality of ARTestBase and also allows us to initialise controllers for testing:

using EvilLink.Database.Test;
using Castle.MonoRail.TestSupport;
using Castle.MonoRail.Framework;
namespace EvilLink.Controllers.Test
{
    public class ConcreteControllerTest:BaseControllerTest{
        // just expose PrepareController as a public method
        public void InitController(Controller controller)
          {           
            PrepareController(controller);
          }
    }
    public class MRTestBase:ARTestBase
    {
        private ConcreteControllerTest context = new ConcreteControllerTest();
        // expose InitController
        public void InitController(Controller controller)
        {
            context.InitController(controller);
        }
    }
}

We can use a dummy implementation of the user context, not tied to the real HttpSession object, to verify the session storage (this would be a good place to use a mock factory).

using EvilLink.Database;
namespace EvilLink.Controllers.Test
{
    public class DummyUserContext:IUserContext
    {
        private int? currentuserid;
        public int? CurrentUserId
        {
            get { return currentuserid; }
            set { currentuserid = value; }
        }
        public User CurrentUser
        {
            get { return currentuserid == null ? 
                null : User.Find(currentuserid); }
        }
    }
}

Writing NUnit tests

We can now write a couple of unit tests inspecting the workflow and session behaviour of the user operations controller. In the setup, we initialise context objects, create a user to play with and prepare the controller. Notice that we just call the constructor and then pass the object to PrepareController and that is it — no black magic involved. We can call the login method and then inspect the user context to check whether the expected user object was stored in the session. We can also try to log in with an incorrect password and verify the message coming out (hint: PropertyBag is a public property of the controller, so we can inspect it directly). The SelectedViewName property will give us a way to check which view was selected for rendering. We can verify that the controller initiated redirection by checking Context.Response.WasRedirected property, but I don’t know of a good way to verify redirection URL at the moment. Jimmy Bogard explored some options for that like changing the redirect method. Apart from that, we can easily test everything else:

using EvilLink.Database.Test;
using NUnit.Framework;
using EvilLink.Database;
using Castle.MonoRail.TestSupport;
 
namespace EvilLink.Controllers.Test
{
    [TestFixture]
    public class TestUserOps:MRTestBase
    {
        DummyUserContext wuc;
        UserOpsController ops;
        User  mike;
        [SetUp]
        public override void SetUp()
        {
            base.SetUp();
            wuc = new DummyUserContext();
            ops = new UserOpsController(wuc);
            InitController(ops);            
            mike = new User("mike", "mike", "mpass", "m@m.com");
            mike.SaveAndFlush();
        }
        [Test]
        public void TestLogin()
        {
            ops.Login("mike", "mpass", "/home");          
            Assert.AreEqual(mike, wuc.CurrentUser);           
        }
        [Test]
        public void TestLoginIncorrectPassword()
        {
            ops.Login("mike", "wrongpass", "/home");
            Assert.AreEqual(null, wuc.CurrentUser);           
            Assert.AreEqual("Username or password incorrect, please try again",
                   ops.PropertyBag["error"]);
            Assert.AreEqual(ops.Name+"\\index", ops.SelectedViewName);
            Assert.AreEqual("/home", ops.PropertyBag["goBackUrl"]);            
        }
        [Test]
        public void TestRegisterUser()
        {
            ops.SubmitRegistration(
              new User("tom", "tsmith", "tpass", "t@t.com"));
            Assert.AreEqual(
             "You have registered successfully. You can now log in.",
                ops.Context.Flash["message"]);
            Assert.AreEqual(true, ops.Context.Response.WasRedirected);
            User u=User.FindAllByProperty("Username", "tsmith")[0];
            Assert.AreEqual("tom", u.Name);
            Assert.AreEqual("t@t.com", u.Email);
        }
    }
}

Build the project, fire up your NUnit test runner, and you should see the tests pass:

Some links for the end

• Source code for this iteration
• More detailed information about BaseControllerTest
• Older library for testing, that works by simulating complete http requests and responses.

Stuff to remember

• BaseControllerTest class from Castle.Monorail.TestSupport provides a framework to unit test controllers.
• Just create the controller as any other object and pass it to the PrepareController method of BaseControllerTest to be able to call its methods directly
• SmartDispatcherController exposes almost everything interesting to verify as public properties, including SelectedView, PropertyBag and Context.

Next exercise

In the next article of this tutorial, we look into injecting services and configuration into controllers using the Windsor dependency injection framework. That article should be online soon. (Subscribe to RSS updates to get notified about that). As I mentioned above, if you are in UK, come to the free session on developing Ajax applications with Monorail that will take place on Thursday 12th to learn more about what Castle can do for you.

For those of you that have just joined this tutorial, this is the third iteration of the EvilLink web application. In the first iteration, we used basic features of ActiveRecord to set up a domain model and back it with a database. In the second iteration, we created a basic web site using Monorail that allowed users to register and log in. If you have not worked with Monorail or ActiveRecord before, read those two articles before continuing with this one.

A quick note before we begin. Hammett from the Castle project was kind enough to correct me about ActiveRecord and mixing domain logic with storage. It turns out that there is a nice way to implement the repository pattern with ActiveRecord directly. Read about the ActiveRecord Mediator that allows that in this post (including the comments).

Unlike the previous two tutorials, this one will not list all the source code for all project classes and web files. We’ll just focus on the most important stuff. You can download the full source code for this iteration from here.

Let’s continue with the remaining user stories:

• As a user, I want to record my web links online, so that I can access them from anywhere.
• As a user, I want to review the links that I previously recorded so that I can visit the interesting sites.
• As a user, I want to edit details and descriptions of the links that I previously recorded, so that I can keep them up to date.

To implement these stories, we will create a new controller to manage links. We will prevent anonymous users from accessing this controller by checking whether the user is logged in, and if not, redirecting them to the login page.

Modifying the model

To implement these stories, we will need to create the Link record type and describe the relationship between users and links. We add a Links collection to User class to record links that the user has registered. It’s best to have the type as a IList interface rather than a particular list to avoid data mapping problems. Instead of [Property], we mark this as [HasMany] to signal that it is a one-to-many mapping.

private IList<Link> links = new List<Link>();
[HasMany]
public IList<Link> Links
{
    get { return links; }
    set { links=value; }
}

The Link class is fairly straight-forward. The only interesting part is the other end of the one-to-many relationship. We mark it as [BelongsTo] and also specify that the Link collection should get saved and updated automatically when the User is saved.

[BelongsTo(Cascade = CascadeEnum.SaveUpdate)]
public User Owner
{
    get { return owner; }
    set { owner= value; }
}

Dynamic binding, AR style

One of the best things about the Castle project is how we can learn and use various components in isolation, but they also have added value when used together. Monorail and ActiveRecord together allow us to write web applications with very little boiler-plate code, focusing just on the business problem at hand. In the second part of this tutorial I explained how to use data binding to automatically populate domain objects from HTTP requests. When ActiveRecord comes into the play, this data binding becomes even more powerful. We can tell Monorail to automatically fetch a record object from the database by ID and have it ready for us to either pass to the view or modify. This is very convenient for actions that should display an object or present a HTML form to edit the object. This is done using the ARFetch attribute instead of DataBind and passing the request field that represents the ID of the related record object. For example, this method signature will automatically fetch a link by id from the database and make it available to us for display:

public void Edit([ARFetch("id")] Link link)

On the way back, we typically want to merge the database object with the request values. There is a shortcut for this as well:

public void Submit([ARDataBind("link",
AutoLoad = AutoLoadBehavior.NewInstanceIfInvalidKey)] Link link)

ARDataBind will first find the object in the database, then populate it with changes from the HTTP request. The only thing left to do is to verify that the link is valid and save it. AutoLoadBehavior specifies what to do if the object is not found — in this case ARDataBind will create a new object, effectively enabling us to use the same method for creating and updating links.

To use these two attributes, our controller has to extend ARSmartDispatcherController, not SmartDispatcherController. The new controller base class and the data load attributes are in the Castle.MonoRail.ActiveRecordSupport.dll library, so add a reference to that DLL as well in your controllers project.

Advanced Monorail concepts

Instead of wrapping up here, let’s see what else we can delegate to Monorail and write less code. Monorail has several more tricks to save time and effort while creating web applications.

Filters

Filters, in Monorail jargon, are methods that are executed before or after controller actions. They allow us to declaratively add infrastructural functionality to the controller code, similar to Aspect Oriented Programming (Windsor provides better support for AOP in general and we’ll discuss this in one of the following articles in this series. Monorail filters are just simple additions to controller code). For example, we can use a filter to instantly prevent anonymous users from calling any action on the Link controller. A filter is specified on the whole controller class with a FilterAttribute. This one will execute the AuthenticatedUserFilter before each action:

[FilterAttribute(ExecuteEnum.BeforeAction, typeof(AuthenticatedUserFilter))]

The filter class (in this case AuthenticatedUserFilter) has to implement the IFilter interface from Castle.Monorail.Framework. The interface has only one method: Perform. If it returns false, the HTTP request processing will stop at that point and will not proceed to the controller. So let’s check if a user is logged in, and if not then redirect the browser to the login page:

using System;
using System.Collections.Generic;
using System.Text;
using Castle.MonoRail.Framework;
 
namespace EvilLink.Controllers
{
    public class AuthenticatedUserFilter: IFilter
    {
        private UserContext userContext=new UserContext();
 
 
        public bool Perform(ExecuteEnum exec, 
          IRailsEngineContext context, Controller controller)
        {
            if (userContext.CurrentUserId == null)
            {              
                context.Response.Redirect("UserOps",
     "index.ashx?goBackUrl="+context.Request.Uri);
                return false;
            }
            else return true;
        }
    }
}

We can now use this filter to quickly mark all controllers that require the customer to be logged in, just by putting an attribute on the class.

Partial templates

NVelocity allows us to reuse view code in different templates by just including the file, using #parse(file) command. This is what Rails calls partial templates. For example, we’ll need to display link details after a user registers that link, but we also need to display the same details when the user browses his links. Instead of copying the same content all over the templates, we can extract that into a common view file and just include it. The important thing to remember is that the path of the included file is relative to the views folder, not the current folder. This is an example of the view that prints links using a partial template:

<h1>My Links</h1>
#if ($links.Count>0)
<ul>
	#foreach( $link in $links)
	<li>
		#parse ("Link/viewLink.vm")
	</li>
	#end
</ul>
#else
You have no saved links.
#end
#parse("Link/newLink.vm")

Helpers

NVelocity language intentionally does not allow you to perform complex scripting, to avoid mixing domain and UI code. But sometimes we want to automate generating HTML code in a more complex language. Monorail allows that with Helpers. Helpers allow us to script the UI formatting in C#. We used a forms helper in the second article of this tutorial, to build a HTML form and pre-populate it with values. There are some other interesting helpers included in the Castle distribution, for example Ajax helpers that generate Scriptaculous effects or help with Prototype communication. You can also write your own helpers and add them to the controllers using the Helper attribute.

View components

View components are a way to re-use parts of the UI dynamically in various pages. This is typically used to manage common parts of the web pages like menus.

I personally don’t use view components that much, because there are different alternatives that can provide the same functionality with just controllers. For view formatting (without any business functionality), it is often better to use Helpers. To loop through a list of objects and reuse the display functionality, I use partial templates (with NVelocity, you can use #parse to include a template file). Parts that reuse business functionality can be implemented using AJAX DIVs as well. So components are really used only when you need to re-use parts of UI that include some business functionality and layout, but you want to process that on the server as part of the same request (so no AJAX).

We use a component in this case to build the top menu bar, that will display links to log in and register if the user is not yet logged in, and display options to add and review stored links and to log out when a user is logged in. The component class is just like a mini-controller with a single action. To implement the component, we need to extend ViewComponent and override the Render method. PropertyBag is available for the component as well (it is actually shared with the controller). Because there is only one method, the component needs to explicitly specify which view gets rendered.

using Castle.MonoRail.Framework;
namespace EvilLink.Controllers
{
    public class MenuBarComponent:ViewComponent
    {
        private UserContext context=new UserContext();
 
        public override void Render()
        {
            if (context.CurrentUserId != null)
                PropertyBag["appuser"] = context.CurrentUser;
            RenderView("default");
        }
    }
}

The view file for the component is similar to the controller view files, but it needs to be in the views\components\MenuBarComponent folder in the web site. To include this component somewhere in the view code, use #component NVelocity extension (this was added for the Castle project and it is not available in the basic NVelocity release). As components are re-usable across pages, they are typically included into the generic layout files, not into individual template views. So here is the changed default layout:

<html>
<head><title>Evil Link v 1.0</title></head>
<link rel="stylesheet" href="$siteRoot/views/layouts/default.css" />
<body>
      #component(MenuBarComponent)
      <hr/>
      #if($message)
      <div class="message">
            $message
      </div>
      #end
 
      #if($error)
      <div class="error">
            $error
      </div>
      #end
 
      $childContent
 
</body>
</html>

Rescues

Monorail Rescues allow us to delegate most common error handling cases, when we just display an error message to the user, to the framework. A rescue is just an alternative view that will be displayed in case of an exception, and passing the responsibility for that to the framework allow us to write less code — instead of try/catch and display error blocks in every action, we just specify an attribute. Rescues can be specified for the whole class or for individual methods, and can be called for a particular exception type or for any exception. For example, to just display an error view in case of any exceptions during processing, we can add a Rescue(“error”) attribute to the controller class. The actual view should be stored in the views\rescues folder of the web site. In the view, we can use $context to reference the rails context. See IRailsEngineContext API docs for more details on that. Most important is the fact that $context.LastException.Message will give us the exception message. So here is a simple rescue velocity file:

<div class="error">
$context.LastException.Message
</div>

Implementing the Link Controller

Armed with all this knowledge, we can now easily implement the link controller. We’ll add a filter to prevent people from using any of the link controller actions if they are not logged in, and we will also not write any error handling code &mdash instead it will be delegated to a rescue. We need to implement actions to register a new link and edit an existing link. After the user submits link details, we store them to the database and display new link information. We also want to enable users to view registered links. For that, we’ll create the following actions:

• NewLink — display a form for a new link
• Edit — display a form to edit an existing link
• MyLinks — view registered links
• Submit — process a form containing link details, either to create or edit a link
• View — view details of a particular link

Edit and View perform the same action essentially, they just load the link details from the database and pass it on to the view to display (but they use different views). We’ll use ARFetch for Edit and View, and we use ARDataBind for Submit. NewLink and Edit should use the same visual template, and MyLinks should use that same template to display links from a collection. For that, we can use the #parse trick.

using System;
using System.Collections.Generic;
using System.Text;
using Castle.MonoRail.ActiveRecordSupport;
using EvilLink.Database;
using Castle.MonoRail.Framework;
namespace EvilLink.Controllers
{
    [FilterAttribute(ExecuteEnum.BeforeAction, typeof(AuthenticatedUserFilter))]
    [Rescue("error"), Layout("default")]
    public class LinkController : ARSmartDispatcherController 
    {
        private UserContext context=new UserContext();
        public void NewLink()
        {
            // just display the form
        }
        public void Submit([ARDataBind("link",
         AutoLoad = AutoLoadBehavior.NewInstanceIfInvalidKey)] Link link)
        {
            if (!link.IsValid())
            {
                PropertyBag["link"] = link;
                Flash["error"] = link.ValidationErrorMessages;
                RenderView("edit");
                return;
            }
            link.Owner = context.CurrentUser;
            link.SaveAndFlush();
            Flash["message"] = "Link saved";
            //redirect after post
            Redirect("view.ashx?id="+link.Id);
        }
        // shortcut for loading the object, don't update it with request values
        public void View([ARFetch("id")] Link link)
        {
            PropertyBag["link"] = link;
        }
        public void Edit([ARFetch("id")] Link link)
        {
            View(link); 
        }
        public void MyLinks()
        {
            PropertyBag["links"] = context.CurrentUser.Links;
        }
    }
}

Key stuff to remember

• Mark one-to-many relationships with [HasMany] and [BelongsTo]
• Reuse parts of templates with #parse
• Use helpers to perform more complex UI scripting with C#, but avoid putting any business functionality into helper classes
• Share business functionality and UI between pages using view components
• Delegate error handling to rescues
• Use Filters for simple aspect-style programming with Controllers to perform authentication, logging and similar actions
• Use ActiveRecord data binding attributes and ARSmartDispatcherController to automatically load objects from the database and merge changes from HTML forms

Next exercise

In the next part of this tutorial, we look into unit testing Monorail controllers. That tutorial should be online early next week. You can download the full source code for this iteration from here.

Meanwhile, you might be interested in coming to the “Developing Ajax Web applications with Castle Monorail” presentation that I will be doing on the 12th of June in London. It’s free, but you have to register up-front. See Skills Matter site for more information.