CQ(R)S And Providing Immediate Feedback In A Web App Using A Service Bus

Written on 20 July 2015

Whenever I'm developing a DDD web app, I'm using CQRS and Domain Events and this means I have a lot of commands and event handlers. Therefore I'm using a durable service bus which means that if the server crashes, all the unhandled messages are sent again to be handled. But I have a problem: all my commands are handled asynchronously because this is how my service bus works. And it works this way because a message can be handled anywhere in that process (usually in a background thread) or in another process if we have a distributed app.

Asynchrony means I can only 'send' a command but I can't expect an answer. Basically it's only

 bus.Send(new DoSomething(){});

and this sucks when application services are implemented as command handlers. Because the user expects some feedback. If the command fails you want to return some error and this is quite tricky in this scenario. The usual solution is to do some client side server polling checking the state of the operation or waiting for a read model. This is obviously cumbersome.

However, we can apply a similar concept but on server side using a mediator. Simply put, we'll have a an object in charge of delivering the command result to our controller. It goes like this in the controller

//constructor
public MyController(IServiceBus bus,ICommandResultMediator mediator) {}


//action
var cmd=new DoSomething();

await _bus.SendAsync(cmd);

var listener = _mediator.GetListener(cmd.Id);

try
 {
     var result = await listener.GetResult<CommandResult>(cancel);

     return Response.AsJson(result);
 }
 catch (TimeoutException)
 {
     return HttpStatusCode.RequestTimeout;
 }

 catch (OperationCanceledException)
 {
     return HttpStatusCode.InternalServerError;
 }

This is NancyFx code but it's easy to understand, instead of returning an ActionResult or directly the model, I'm returning a NancyResponse which can be a HttpStatusCode as well. This is not important, the important part is the use of the mediator. We send the command to be handled then we ask the mediator for a listener that will be used to await the command result. If the result doesn't arrive in a couple of seconds or if the operation is cancelled, exceptions are thrown.

Now here's how the command handler looks like

class DoSomethingHandler:IExecute<DoSomething>
{
  public DoSomethingHandler(ICommandResultMediator mediator) { }

  public void Execute(DoSomething cmd)
  {
    //do stuff
    //get result
    var result=new CommandResult();
    result.AddError("stuff","Stuff happened");
    _mediator.AddResult(cmd.Id,result);
  }
}

In the handler we do things as usual, the only change is that now the result is sent to the mediator. And here is the mediator itself

public class CommandResultMediator : ICommandResultMediator
   {

       public CommandResultMediator()
       {
           ResultCheckPeriod = 100;
       }
       public void AddResult<T>(Guid cmdId, T result) where T :class
       {
           Listener l = null;
           if (_items.TryRemove(cmdId,out l))
           {
               l.Result = result;
           }

       }

       /// <summary>
       /// How often to check if a result has arrived, in ms.
       /// Default is 100 ms
       /// </summary>
       public int ResultCheckPeriod { get; set; }

       void Remove(Guid cmdId)
       {
            Listener l = null;
           _items.TryRemove(cmdId, out l);
       }

       public int ActiveListeners
       {
           get { return _items.Count; }
       }

       ConcurrentDictionary<Guid,Listener> _items=new ConcurrentDictionary<Guid, Listener>();

       public IResultListener GetListener(Guid cmdId,TimeSpan? timeout=null)
       {
           timeout = timeout ?? TimeSpan.FromSeconds(5);
           var listener=new Listener(timeout.Value,cmdId,this);
           listener.UpdatePeriod = ResultCheckPeriod;
           _items.TryAdd(cmdId, listener);
           return listener;
       }


       class Listener:IResultListener
       {
           private readonly Guid _cmdId;
           private readonly CommandResultMediator _parent;

           public Listener(TimeSpan timeout, Guid cmdId, CommandResultMediator parent)
           {
               _cmdId = cmdId;
               _parent = parent;
               TimeoutTime = DateTime.Now.Add(timeout);
           }

           private DateTime TimeoutTime { get; set; }

           public object Result { get; set; }

           public int UpdatePeriod=100;

           public async Task<T> GetResult<T>(CancellationToken cancel=default(CancellationToken)) where T : class
           {
               while(Result==null)
               {
                   if (DateTime.Now >= TimeoutTime)
                   {
                       _parent.Remove(_cmdId);
                       throw new TimeoutException();
                   }
                   if (cancel.IsCancellationRequested)
                   {
                       _parent.Remove(_cmdId);
                       throw new OperationCanceledException();
                   }
                   await Task.Delay(UpdatePeriod,cancel).ConfigureAwait(false);
               }
               return Result as T;
           }
       }
   }

Btw, the mediator should be a singleton managed by your favourite DI Container.

Note that the mediator is part of my CavemanTools library so if you're using it, or SqlFu or MvcPowertools you only need to update to the last version.

So pretty much that's it! The easiest way to return a result from an async command handler.

Make Your CQRS Web App More Maintainable With a Generic Controller

Written on 18 July 2015

From a design point of view if you want a proper separation of concerns (SoC) in a web app, it looks like this

  • You have a controller/action "in charge" of a http request
  • The controller maps the request to a command (input data)
  • The controller invokes an application service passing the input data. In a CQRS app, you might have a command send to a command handler, which is the implementation of an application use case, ergo an application service.
  • The service updates the domain objects then persists them. Domain events are published if you're using the domain events pattern.
  • The service returns a result which is mapped by the controller to a http response.

You want to keep the controllers very slim because their purpose is just to act as adapter between the web and the application services. The actual app behaviour is in the application service. So for each use case we'd have an application service and a controller/action which will invoke it. And this can become very boring quickly.

Problem: Repetitive boilerplate code required to respect SoC

Some devs will consider that DRY is a good reason to violate SoC so they merge a controller with an application service. Everything that should be in that service is put in a controller. While it works it does have a big drawback: it's so easy to couple yourself to the MVC framework. Add an ORM into the mix and the controller becomes a part of persistence as well. This is more prevalent for Query controllers.

While some apps are trivial enough that we don't need to bother with abstractions and SOLID principles, if you actually build a business app or at least some app that will evolve in time and you want it maintainable, the above "pragmatic" solution will slowly lead to a ball of mud.

We want SoC but we don't want to have hundreds of repetitive controllers with 1-2 lines that in the end amounts to "call some service" and return a result.

Solution: Enter the Generic Controller

What we want is to have one controller where to put all the repetitive bits (validation,specific authorization, common errors scenario handling) that will act as a "host" for any app service (the Command part of CQRS) or query handlers (the Query part of CQRS).Yes, one controller to rule'm all. Or several, because you want specific customizations for some parts of your app.

In a nutshell it look like this (although this list is common for both command/query there would be a specific implementation for each case):

  • Controller is invoked for a route pattern which captures a command/query name
  • Based on the name (or other convention), the request is mapped to the corresponding model (a command/query) i.e AddUser or GetUser . Note that these are inputs, not handlers.
  • For commands basic validation can be performed
  • Other common stuff, like ensuring the user is authenticated (if you need it) or populating the model with common information like the user id
  • Use case specific behaviour. This is basically aspect oriented programming. We annotate the model with attributes that will trigger specific behavour in the controller. An example is to check if the curent user is Admin or has the CanManageUsers permission. Or that the model expects a certain property populated.
  • Based on the input model, a service/query handler is selected then executed and a result is returned.
  • A non-null result is then returned as Json (for a Api) or a view model.
  • A convention can say that if a result is null then return a 406 status (Not acceptable) for a Api or some error page.

Implementation

Be aware that the implementation varies according to your app's needs. The only thing generic (sic) enough is the principle, the code needs to be adapted to your situation. This means the example below is not meant to be copy/pasted, it just shows you a concrete implementation. The code is an excerpt from the project I'm working on (while my project uses NancyFx I'm gonna show you asp.net webapi/mvc implementations).

But first, let's see what we have and what we need. I'm using CQRS all the way up (or down) so my application services are command handlers while querying is done by query handlers (which work directly with the db). For both my convention is to have one unique model in, one model out. I also have specific interfaces for each case

class AddUserService:IHandleCommand<AddUser,CommandResult>
{
    public CommandResult Handle(AddUser cmd){ }
}

class GetUsersQuery:IHandleQueryAsync<GetUser,UserInfo[]>
{
  public Task<UserInfo[]> Handle(GetUser query){ }
}

Each service handles one or more related commands, the name isn't important but the abstraction is, because this is how we'll ask the DI Container the service/query handler we need. But remember that in our controller we only have a name extracted from the url. We need a way to map that name to our input and to detect the correct service that will handle the command/query.

For that, I've come up with the following class (this needs to be adapted to your specific needs)

public class ServiceHandlersCache
  {
      Dictionary<string,ServiceHandlerItem> _items=new Dictionary<string, ServiceHandlerItem>();

      //scan and register the input/result models from the found command/query handlers
      public void AddHandlers(Assembly asm)
      {
          var types = asm.GetPublicTypes(t => !t.IsAbstract && (t.ImplementsGenericInterface(typeof(IHandleCommand<,>)) || t.ImplementsGenericInterface(typeof(IHandleQueryAsync<,>)))).ToArray();
          asm.GetTypesDerivedFrom<RequestInput>()
              .ForEach(t =>
              {
                  var result = FindResultModel(t, types);
                  if (result==null) return;
                  var item=new ServiceHandlerItem(t,result);
                  _items.Add(item.CmdId,item);
              });

      }

      public ServiceHandlerItem GetModels(string cmdId)
      {
          return _items.GetValueOrDefault(cmdId);
      }

      static Type FindResultModel(Type input,Type[] types)
      {
          var result = types.Select(t =>
          {
              var interAll =
                  t.GetInterfaces()
                      .Where(i => i.Name.StartsWith("IHandleCommand") || i.Name.StartsWith("IHandleQueryAsync"));
              var inter = interAll.FirstOrDefault(i => i.GetGenericArgument() == input);
              if (inter==null) return null;
              return inter.GetGenericArgument(1);
          }).FirstOrDefault(d=>d!=null);
          return result;
      }
  }

  public class ServiceHandlerItem
   {
       public Type Input { get; set; }
       public Type ResultModel { get; set; }

       public string CmdId
       {
           get { return Input.Name; }
       }

       public RequestInput CreateInputInstance()
       {
           return Input.CreateInstance() as RequestInput;
       }

       public AccountRights[] RequiredRights { get; private set; }

       public ServiceHandlerItem(Type input, Type resultModel)
       {
           Input = input;
           RequiredRights=input.GetAttributeValue<RequiresAttribute, AccountRights[]>(a => a.Right);
           ResultModel = resultModel;
       }
   }

ServiceHandlersCache, which is used as a singleton, maintains a cache of the input/result models which is injected into the controller. Given an identifier it returns the input/result models that will be used by the controller. While I'm using this mainly for Api purposes, it can be easily adapted to web sites.

[Requires(AccountRights.ManageUsers)]
public class AddUser:RequestInput
{

}

 //controller constructor
  public GenericController(ServiceHandlersCache cache) {}


//actions
  [Route("api/{cmdId}")]
  [HttpPost]
  [Authorize]
public CommandResult Post(string cmdId)  
{
   var models=_cache.GetModels(cmdId);

  //handle null scenario {}

   var cmd=models.CreateInputInstance();

   this.TryUpdateModel((dynamic)cmd);

   if (!ModelState.IsValid){
     var result=ModelState.ToCommandResult();//ext method
     return result;
   }

  //ext method to check for specific AccountRights if the model has it
    if (!this.HasAnyOfRights(models.RequiredRights)){
    return null;
  };

  var result=cmd.ExecuteAndReturn(models.ResultModel) as CommandResult;
  return result;
}

ExecuteAsyncAndReturn is an extension method that uses the Di Container to create the service implementing IHandleCommand<Input,Output> then executes it returning the result.

For query handlers we have a similar action

  [Route("api/{queryId}")]
  [HttpGet]
public Task<object> Get(string queryId)
{
  var models = _cache.GetModels(queryid);

  if (!this.HasAnyOfRights(models.RequiredRights)){
    return null;
  };

    var query = models.CreateInputInstance();

    var result = await cmd.QueryAsyncTo(models.ResultModel, cancel);

    return result;  
}

I'm using POSTs to identify commands and GETs to identify queries. We can create additional attributes to annotate the input model and based on them, invoke a specific behaviour in our controller. Those behaviours are basically decorators that need to be generic enough to be reusable. Until now, in my app I didn't need more than permission checking.

The point here is to extract the repetitive infrastructural behaviour into a controller and action filters. This allows us to focus only on the actual app behaviour. Adding a new use case means adding a new command, handler, validator i.e all the new things required, but not the boilerplate stuff like controllers/actions. Instead of having 10 services, 15 queries and 25 controller actions, I now have 10 services, 15 queries and 2 controller actions. Less code, DRY code.

Of course, the great benefit here is decoupling of the app service from the api/mvc framework. Our app service knows only about its input (nothing http or UI framework related) and the controller just prepares that input from a request. If the service needs a user id or an Ip, the input model can be decorated with an attribute that will tell the controller to populate that specific property from the model.

Note that I'm not using a service bus in this example although I am using one in my app, but that's a special case that I'll handle (pun intended) in the next post.

Aurelia With Razor Views And NancyFx

Written on 06 July 2015

I've been toying these days with aurelia js trying to do some tutorials and understand how I can integrate it with my current NancyFx app (I'll have several aurelia apps each dealing with a certain aspect of my project). Each aurelia app has the sources (html views, razor view and view models written in typescript) in a directory where it makes sense (e.g: ~/Account/Settings) next to nancy modules, specific services etc (in case you're wondering, I'm using a business component based architecture where everything related to a component is in one directory, regardless of the technical aspects). The resulting static assets (js, maps, plain html) are copied to a /content/[app name] directory.

The Problem

Aurelia views are, by convention, in the same place and have the same name as the view model in my case, in the /content/[app] directory. Not really an issue, however I need some views to be generated i.e to be cshtml files which are found elsewhere. I can configure aurelia to look for views not ending in html, but I don't want every view to be a Razor file. Most of the views are plain html and only some of them need processing.

Basically, I need a way to use both simple html files and Razor views with minimal fuss.

Solution

After some thinking I came to the conclusion that it's better to implement everything server side. From aurelia's point of view every request is for a .html file. It's up to nancy detect which is which and to server either a static file or a processed razor view. By default, the /content directory is designated to contain only static assets so I needed a convention to filter the html files.

However, I need a way to mark that some html requests are for razor templates. Since every Razor view has a view model, I've decided to create an attribute which will mark a view model (and by convention the view) as an aurelia view.

  public class AureliaAppAttribute:Attribute
    {
        public string AppName { get; set; }

        public AureliaAppAttribute(string appName)
        {
            AppName = appName;
        }
    }

As I've said, I have more than one aurelia app, so each view model needs to declare to which app it belongs. For the ~/Account/settings app, any view model declared in that directory(and children of it) will be decorated with [AureliaApp("settings")].

Then I have an object which will recognize the aurelia view requests that are Razor views. I need that in order to filter the requests and allow the static html files to be served normally.

public class AureliaRouter
   {
       public static bool IsAureliaViewModel(Type t)
       {
           return t.HasAttribute<AureliaAppAttribute>();
       }

       public static string ContentDir = "/content";

       Dictionary<string,Func<object>> _handlers=new Dictionary<string, Func<object>>();


       public bool IsAureliaView(string path)
       {
           return _handlers.ContainsKey(path);
       }

       public object GetModel(string path)
       {
           return _handlers.GetValueOrDefault(path,()=>null)();

       }

       public void AddView(Type viewModel)
       {
           var appName = viewModel.GetAttributeValue<AureliaAppAttribute, string>(a => a.AppName);
           var url = ContentDir + "/" + ExtractViewPath(viewModel.Namespace, appName) + "/" +
                     viewModel.Name.RemoveLastChars(5).ToLower()+".html";
           _handlers.Add(url,viewModel.CreateInstance);
       }

       static string ExtractViewPath(string nspace,string appName)
       {
           var idx = nspace.IndexOf(appName);

           return nspace.Substring(idx,nspace.Length-idx).Replace('.', '/');
       }
   }

//search and register the view models
public static void RegisterAureliaViews()
       {
           typeof (RoutingUtils).Assembly.GetPublicTypes(AureliaRouter.IsAureliaViewModel)
               .ForEach(t=>_aurelia.AddView(t));
       }

This object simply computes the url that would match the razor view, based on a view model. So for a view found in ~/Account/Settings/foo/bar.cshtml it will generate the path /content/settings/foo/bar.html which is what aurelia will request. Once we have this we can filter the requests by setting our static content conventions in the nancy bootstrapper.

          nancyConventions.StaticContentsConventions.Clear();
           nancyConventions.StaticContentsConventions.Add(StaticContentConventionBuilder.AddDirectory("content",null,"js","css",".map"));
           nancyConventions.StaticContentsConventions.Insert(0, (ctx, root) =>
           {
               var req = ctx.Request.Path;
               if (req.StartsWith("/content") && req.EndsWith("html"))
               {

                   if (RoutingUtils.Aurelia.IsAureliaView(req))
                   {
                       return null;
                   }

                     var file = Path.GetFullPath(Path.Combine(root, req.TrimStart('/')));
                   return new GenericFileResponse(file, ctx);
               }

               return null;

           });

Now, since I have no clue how I can return a razor View from the static content handler, I'll need a module which will handle the requests for the razor files. Here it is in all its glory.

public class AureliaViewsModule:NancyModule
    {
        public AureliaViewsModule()
        {
            Get[@"/content/^([a-z\.\/]*\.html)$"] = _ =>
                View[RoutingUtils.Aurelia.GetModel(Request.Path)];

        }
    }

And one more thing, all razor views need to to have an empty layout, we want the template only.

If you're using Asp.Net Mvc, the approach is very similar, you can filter and return a proper view/static template from an action filter.

Functional Programming Holy Wars

Written on 19 June 2015

These days functional programming seems to be the trend. And with the help of languages like F# , many programmers seem to embrace the functional paradigm. And these folks are very passionate about this, some of them on the verge to look like zealots which go on great length to convert the "unbelievers".

Personally, I use very little functional programming (FP), only when it appears as a "natural" solution i.e it makes sense for the problem I'm solving to express its solution as a pipeline of functions. I have a predominant object oriented mindset which fits me very well. This means I do prefer languages like C# and I have no interest in languages like F#.

It seems like FP looks like the new golden hammer for some developers, who now hails it as the best way to do everything. I disagree with this. It certainly fits some use cases, but in my case, it's just a tool I'm using very sparingly. And to be honest, I don't like the F# syntax so I won't be using it any time soon.

But not being a 'believer' seems to upset some people. They demand you to explain yourself and you better have a very good reason (read: one that they agree with) to reject the new tool. If you say to them that you've evaluated the paradigm/tool and it doesn't add much value for you, it's a sign you need more convincing. If you resists, you're just a close minded old dinosaur who doesn't want to be enlightened.

I think the cult-like mindset of some of the fans is harmful. I've noticed that developers are always looking for the next silver bullet, platinum hammer, the ultimate solution, recipe, mindset etc that will solve of our problems. And I know this will never happen. It's cool there is a new language enabling a non mainstream paradigm of doing things, but not everyone needs it and not everyone will like it. As long as a developer can build mainatainable solution in their language of choice, it's fine by me. Yes, even if that language is javascript, ruby or php. In the end, they're all tools and we should be more concerned about the quality of the result and less about using a specific tool.

As a funny note, I am a big fan of DDD. I consider that it should be used for every project, as a strategic tool, of course. Personally, I'm using it this way even if lately I find myself writing a lot of CRUD stuff. But I've used the DDD mindset to reach the conclusion that in the end I'm dealing with many CRUD use cases. Some people said DDD is OOP done right and I agree with them. It fits my mindset naturally. But DDD can be implemented in a functional way too and some devs are using it this way.

In conclusion, I and other developers will continue to use our OOP mindset and languages because it makes the most sens to us. Other devs will use functional programming. I don't think it should be a 'war' about which is better and which is the one true way. I agree with FP fans that FP is not very well known and it will benefit programmers (at least some of them) to be aware of it.

If you have an opinion about why FP is great or why it sucks feel free to send me a PR.

How To Use Razor with NancyFx

Written on 16 June 2015

After using Nancy to build an Api app, I've decided to give it a try and use it instead of Asp.Net Mvc. I was a bit weary because I knew things are not that straightforward when it comes to Razor. Turns out I was partially right.

But first things first. The docs do a pretty good job explaining how to configure Razor, however there are some gotchas.

  1. Every bit of code you'll use in a razor view if it happens to be in a different assembly than the view, needs to be manually referenced, regardless if the current assembly reference it and your view has the required using statement. Coming from Asp.net Mvc you might be tempted to configure razor in app/web.config. Personally, I find it easier to use the programmatic option, that is implementing IRazorConfig. Now, everytime you need an assembly referenced in a Razor view just add it to that class.

Here's an example

 public class RazorConfig : IRazorConfiguration
   {
       public IEnumerable<string> GetAssemblyNames()
       {
           yield return "System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a";
           yield return "Common";

           yield return "HtmlTags";

       }

       public IEnumerable<string> GetDefaultNamespaces()
       {
        //contains html extensions
        yield return "Web._Auxilia.Html";

       }

       public bool AutoIncludeModelNamespace
       {
           get { return true; }
       }
   }

While my webapp references System.Web and other assemblies, I still need to include it here for Razor to know about it. And this needs to be done when refactoring moves some code (used by the view) from one assembly to another or one namespace to another.

  1. All of your views need the @inherits Nancy.ViewEngines.Razor.NancyRazorViewBase<My_Model> with full path for the view base, instead of @model MyModel . This is easily solvable with a file template (at least if using Resharper).

  2. When defining a view convention the path should not start with '/' .

View Conventions

And speaking of view conventions, this is a very nice part of Nancy (you can get a similar feature in Asp.Net Mvc using my MvcPowerTools library) that allows you to configure the view path you want. This means that you can put your some of your views in a View directory, others in next to the Nancy module or the view model itself. All these with just a couple lines of code.

Here's an example

 //in my nancy bootstrapper
protected override void ConfigureConventions(NancyConventions nancyConventions)
       {
           ConfigureViews(nancyConventions);
       }

       private static void ConfigureViews(NancyConventions nancyConventions)
       {
           nancyConventions.ViewLocationConventions.Clear();
        nancyConventions.ViewLocationConventions.Insert(0, (view, model, ctx) => "{1}/{0}".ToFormat(view, ctx.ModulePath));
           nancyConventions.ViewLocationConventions.Add((view, model, ctx) =>
           {
               var tp=(model.GetType() as Type);
               var asm=tp.Assembly.GetName().Name;
               var path = tp.Namespace.Substring(asm.Length+1).Replace('.','/');

               //path is model namespace without the assembly name
               return "{0}/{1}".ToFormat(path,view);
           });

           nancyConventions.ViewLocationConventions.Add((view, model, ctx) => "common/{0}".ToFormat(view));
       }

Since I don't want to use any existing conventions, I clear the list and define my own. The first convention tells the engine to look for the view in a directory that has the same name as the module path. This usually happens if the module is used to define an equivalent to a asp.net mvc area. And usually, the module itself is in a directory with that name.

The next convention is the most interesting one. It's for views sitting next to their view model. While in asp.net mvc returning a View(model) meant the view name is the action name found in a controller (or Shared) directory, in Nancy return View[model] looks for a view with the model type name (but without the "Model" suffix). And this might be strange but it's actually a great feature: just look at the view/model name and you already know the model/view name ;) . Also this means you should use one view model per view. And as a tip, always define a view model even if you plan to reuse an existing data structure. It's a very small price to pay for maintainability.

As you can see there's no view extension mentioned. That's because the view locator searches for all files with that name regardless of their extensions and then uses the found extension to identify the view engine. This way, switching for Razor to Spark (for example) means you just have to install the Spark view engine and your code stays untouched.

Html Tags and Helpers

In this regard, you don't have much. While there is a nuget bringing the asp.net mvc html helpers to Nancy, it's pre release and it's a port. This is not wrong, but I do prefer a more fluent (read: not ugly) way of doing things. Besides writing the html code directly , which I don't recommend as a general thumb rule, you can use the HtmlTags library to define your own Html Helpers for Nancy. It's more work but it's trivial and you get some cool benefits.

Here's an example of a 'register user' form

 <form action="/register" method="POST">

    @Html.HiddenTag(d=>d.OperationId).Raw()
    <div class="form-group">

        @Html.Label(d=>d.Fullname).Raw()
        @Html.Textbox(d=>d.Fullname).AddClass("form-control").Raw()
        @Html.ValidationText(d=>d.Fullname).Raw()

    </div>
    <div class="form-group">

        @Html.Label(d=>d.Email).Raw()
        @Html.Textbox(d=>d.Email).Raw()
        @Html.ValidationText(d=>d.Email).Raw()

    </div>
    @Html.FormField(d=>d.Password,()=>Html.Textbox(d=>d.Password).PasswordMode())

    <div class="form-group">
        <input type="checkbox" name="RememberMe" value="true"/><label>Remember Me</label>
    </div>

    <button type="submit">Go</button>

 </form>

All the helpers are defined by me, they just provide a simple way to use HtmlTags in a Razor view. Here's a small excerpt

      public static TextboxTag Textbox<T>(this HtmlHelpers<T> html,Expression<Func<T,object>> valueSelector)
       {
           var name = valueSelector.GetName();
           return html.Textbox(name);
       }

      public static TextboxTag Textbox<T>(this HtmlHelpers<T> html, string name)
      {
          var val = html.Model.GetPropertyValue(name) ?? "";
          return new TextboxTag(name, val.ToString()).IdFromName();
      }

       public static HiddenTag HiddenTag<T>(this HtmlHelpers<T> html, Expression<Func<T, object>> valueSelector)
       {
           var name = valueSelector.GetName();
           var result= new HiddenTag();
           result.Name(name).IdFromName();
           return result;
       }

      public static IHtmlString FormField<T>(this HtmlHelpers<T> html, Expression<Func<T, object>> valueSelector,
           Func<HtmlTag> factory = null)
       {
           if (factory == null)
           {
               factory = () => html.Textbox(valueSelector);
           }
           var result = new DivTag().AddClass("form-group");
           result
               .Append(html.Label(valueSelector))
               .Append(factory())
               .Append(html.ValidationText(valueSelector));
           return result.Raw();
       }

       public static HtmlTag ValidationText<T>(this HtmlHelpers<T> html, Expression<Func<T, object>> valueSelector)
       {
           var name = valueSelector.GetName();
           return html.ValidationText(name);
       }
       public static HtmlTag ValidationText<T>(this HtmlHelpers<T> html, string name)
       {
           var result = html.RenderContext.Context.ModelValidationResult;
           if (result.IsValid) return HtmlTag.Empty();
           var error = result.Errors.GetValueOrDefault(name, new ModelValidationError[0]).FirstOrDefault();
           if (error==null) return HtmlTag.Empty();
           var tag=new SpanTag();
           tag.Text(error.ErrorMessage);
           return tag.AddClass("error");
       }

       public static IHtmlString Raw(this HtmlTag tag)
        {
            return new NonEncodedHtmlString(tag.ToString());
        }

Some interesting things:

  • All (almost) helpers return a HtmlTag object or a type inheriting HtmlTag
  • Because Razor html encodes everything, we need to tell it to not encode the tag, hence the Raw() extension method
  • Validation result object (created by a call to Validate or BindAndValidate in a Nancy module) can be found at [html helper].RenderContext.Context.ModelValidationResult . That's where the ValidationText takes the errors messages from.

Creating your own helpers means it's easier to add changes later. For example, I can decide to create a helper AsSubmit() for a button or link tag, which can add or remove a specific css class or attribute or include directly a css class for a specific tag (such as "form-control" for textboxes). HtmlTags library has some support for defining your own html conventions (that can manipulate tag generation based on model) but the docs are lacking in this regard, AFAIK is still work in progress.

Conclusion

Clearly, using Razor with Nancy is not as smooth as with Asp.Net Mvc, but for me it's not a big deal. I like Nancy as a framework and the 'price' for using razor is quite small once you have a workflow defined. Actually, I'd say it's easier for a asp.net veteran to write a maintainable app with Nancy, while it's easier for a beginner to use Asp.Net Mvc. You can do everything with both, but with Nancy you are more in control.