We’ve now run through the initial wizard to get our starting Monorail application up and running. We’re now going to explore what the wizard has generated for us.

Solution StructureSolutionExplorer

Here’s our generated solution with our web project and our test project. Monorail is an MVC web framework and the wizard has generated a project structure for us for containing our Models, Views and Controllers. We also have a folder for static content and the Windsor integration has given us a config folder.

Our Models folder contains our starting business objects/entities. As our application grows, these might get pushed out into their own project to form a domain model or they may stay as a presentation model. For now we’ll gloss over them a little at least until we explore Castle Active Record.

The views and controllers have a linked structure as each controller has a corresponding folder under the views folder. These individual view folders then contain a .vm file for each action that can be performed on the controller. These .vm files are the NVelocity templates and contain our presentation only, including some lightweight presentation logic to loop over collections or other presentation specific operations.

Now, looking at the controllers folder we have 3 controllers listed (Contact, Home and Login) along with BaseController. If we look further we can see that each of the 3 controllers inherits from BaseController, which in turn inherits from SmartDispatcherController. In Monorail, a controller is a class that inherits from Controller but usually you will use the SmartDispatcherController as this provides us with some very powerful data binding capabilities.

A closer look at a controller

OK, so let’s crack open one of our starting controllers and see what we can find. Since we are on the home/index.castle page then let’s pick on the HomeController as this is the one that maps to our current page.

Looking inside HomeController we have 2 public methods called Index and BlowItAway. Both are actions on the controller and our current page of home/index.castle maps to the Index method.

Within the Index method we see an assignment to PropertyBag. The PropertyBag is one of a couple of ways of passing information over to a view from the controller. By assigning DateTime.Now to PropertyBag[“AccessDate”] we are giving the view the current time via a view variable of “AccessDate”. If we open up the Views/Home/Index.vm file we can use this variable. Find the <div id=”greeting”> line and add the following new div below it:

<div>The time is $AccessDate</div>

Save the Index.vm file and refresh your browser. You should now see the date and time output. At the moment it doesn’t look very pretty but notice how we’ve output a dynamic variable without jumping through the usual ASP.NET escaping into server code in the page. Our usual way of doing this would be something like <div>The time is <%= DateTime.Now %></div>.

Not only that, but we haven’t embedded the logic of using DateTime.Now within the page itself. The controller is where we decide this type of logic and the view itself remains very light. In my mind this is one of the big benefits of using Monorail, it is naturally guiding us to separate our logic from our views. This is possible with web forms but it’s something we have to enforce ourselves and it is very easy to slip back into bad habits (well, it is for me anyway).

But now lets fix the ugly nature of our date time format. Change the view code to <div>The time is $AccessDate.ToString(‘HH:mm’)</div>. Now we get just the time output. NVelocity is dynamically calling the ToString for us.

But have we just mixed logic that the controller should be handling for us? That depends. If it’s something that needs to be enforced and testable then keep the view light and just output $AccessDate and change the controller to push the correctly formatted time into the property bag.

OK – this wraps it up for our explore of the starting application for now. For our next post we’ll add a new controller and wire it up with Windsor.