So this week we got to start working a brand spanking new MVC project. So far we're leveraging Castle Windsor, NHibernate, Fluent Nhibernate, and kind of running Linq to NHibernate. It's amazing how quickly you can get a project up and running in such a short amount of time. (BTW, Fluent NHibernate rocks!) When you're building off the trunk of these projects, it's almost like the contributors to all these great projects are extended members of the team. Thank you all!

Moving on... One of the things that are cool, but also slightly annoying, is how the MVC framework parses out items from the http payload to populate any input arguments on controller actions.

It's great how it just works, but it's a little annoying if it's under test and you have to add more fields, or remove fields from a form, then you have to go update the signature of the action then go update the test.... yada yada The changes just ripple down...

So one thing we tried out this week was to create a payload parser. What this guy does is take a DTO parse out the values for each of the properties on the DTO from the current requests payload and fill it. This makes it easy to package up the form parameters in a nicely packaged DTO and fire it off down to a service layer to do some work.

So instead of declaring an action method on a controller that looks like this, where the signature would have to change based on what fields are submitted on a form:

ViewResult register_new_account(string user_name, string first_name, string last_name)

We can write this...

          public ViewResult register_new_account()
{ var accountSubmissionDTO = parser.MapFromPayloadTo<AccountSubmissionDTO>();
var validationResult = task.Validate(accountSubmissionDTO); if (validationResult.IsValid)
{ task.Submit(accountSubmissionDTO); return View("Success",
accountSubmissionDTO); } return View("Index",
validationResult.BrokenRules); }

This better allows us to adhere to the OCP. If we need to include additional fields on the form, we can add them to the form as long as the control name is the same as the name of the property on the DTO that it will be bound to. The implementation of the payload parser is quite primitive for now, but at the moment it's all that we needed.

First up the specs... simple enough, for now!

          public
          class when_parsing_the_values_from_the_current_request_to_populate_a_dto
: context_spec<IPayloadParser> { [Test] publicvoid should_return_a_fully_populated_dto()
{ result.Name.should_be_equal_to("adam"); result.Age.should_be_equal_to(15);
result.Birthdate.should_be_equal_to(new DateTime(1982, 11,
25)); result.Id.should_be_equal_to(1); } protectedoverride IPayloadParser
UnderTheseConditions() { var current_request = Dependency<IWebRequest>(); var
payload = new NameValueCollection(); payload["Name"]
= "adam"; payload["Age"]
= "15"; payload["Birthdate"]
= new DateTime(1982, 11, 25).ToString(); payload["Id"]
= "1"; current_request.setup_result_for(r =>
r.Payload).Return(payload); returnnew PayloadParser(current_request);
} protectedoverridevoid BecauseOf()
{ result = sut.MapFromPayloadTo<SomeDTO>(); } private SomeDTO
result; } publicclass when_parsing_values_from_the_request_that_is_missing_values_for_properties_on_the_dto
: context_spec<IPayloadParser> { private AccountSubmissionDTO
result; [Test] publicvoid it_should_apply_the_default_values_for_the_missing_properties()
{ result.LastName.should_be_null(); result.EmailAddress.should_be_null(); } protectedoverride IPayloadParser
UnderTheseConditions() { var current_request = Dependency<IWebRequest>(); var
payload = new NameValueCollection(); payload["FirstName"]
= "Joel"; current_request.setup_result_for(x =>
x.Payload).Return(payload); returnnew PayloadParser(current_request);
} protectedoverridevoid BecauseOf()
{ result = sut.MapFromPayloadTo<AccountSubmissionDTO>(); } } publicclass SomeDTO
{ publiclong Id { get; set; } publicstring Name
{ get; set; } publicint Age {
get; set; } public DateTime Birthdate { get; set; } }

The current implementation:

          public
          interface IPayloadParser
{ TypeToProduce MapFromPayloadTo<TypeToProduce>() where TypeToProduce
: new(); } publicclass PayloadParser
: IPayloadParser { privatereadonly IWebRequest
current_request; public PayloadParser(IWebRequest current_request)
{ this.current_request = current_request; } public TypeToProduce
MapFromPayloadTo<TypeToProduce>() where TypeToProduce
: new() { var dto = new TypeToProduce(); foreach (var
propertyInfo intypeof (TypeToProduce).GetProperties())
{ var value = Convert.ChangeType(current_request.Payload[propertyInfo.Name],
propertyInfo.PropertyType); propertyInfo.SetValue(dto, value, null);
} return dto; } }

So last week the guys and I at work started to spike ASP.NET MVC. We're starting up a new project, and decided to take advantage of the Preview 2 version of the so far released libraries. Our experiences so far have been.... hmmm... not as expected.

Here's a few things we've learned, hopefully they help someone else out. We're nant junkies, so the first thing we did to get going was automate the compiling, testing, running, deploying, and creation of the database with nant. We found that when running our project against the aspnet_compiler.exe that it didn't recognize some of the new C# 3.0 syntax.

          <
          select 
          name
          ="protocolName"> 
          <%
          foreach( var dto in ViewData
) {%> <option><%= dto.ProtocolName %></option> <% } %> </select>

The above code would raise an error with the aspnet_compiler.exe. Now this is valid C# 3.0, but the pre compiler didn't know what to do with the "var" keyword. Next, the precompiler didn't know where to find the "Form()" method on the Html helper class because, it's an extension method.

          <%
          using(
Html.Form( Controllers.Order.Name, "submit", FormMethod.Post
) ) {%> 

It's kind of an interesting idea that so many methods on the "HtmlHelper" class are extension methods. The solution to getting the aspnet_precompiler to recognize the C#3.0 syntax was to dump this block of xml in the web.config.

          <
          system.codedom
          >
<
          compilers
          >
<
          compiler 
          language
          ="c#;cs;csharp" extension=".cs" warningLevel="4" type="Microsoft.CSharp.CSharpCodeProvider,
System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
<providerOption name="CompilerVersion" value="v3.5"/>
<providerOption name="WarnAsError" value="false"/>
</compiler>
</compilers>
</system.codedom>

Next up... testing controllers. I think the guys and I were a little surprised at just how awkward it was to test a controller. I thought, a lot of time was spent making the controllers more testable. Our first pain point was the fact that "RenderView()" is a protected method on the Controller base class. Here's what I'm talking about...

          public class 
          HomeController : Controller { public
void Index( ) { RenderView( "Index" );
} public void About( ) { RenderView( "About" );
} }

So let's think... how can we test that when the Index action is invoked it calls "RenderView" with an argument value "Index"... So some people have suggested creating a Test Double. I say... booo... I use mock object frameworks so that I don't need to groom a garden of hand rolled test stubs. Here's what we came up with... first cut remember!

          public class 
          OrderController : BaseController, IOrderController { private
readonly IOrderIndexCommand indexCommand; private
readonly ISubmitOrderCommand submitCommand; public OrderController( IOrderIndexCommand indexCommand, ISubmitOrderCommand submitCommand
) { this.indexCommand = indexCommand; this.submitCommand
= submitCommand; } public void Index( ) { indexCommand.InitializeWith( this );
indexCommand.Execute( ); } public void Submit( )
{ submitCommand.InitializeWith( this ); submitCommand.Execute(
); } }

Ok... so it's slightly more testable. Each action on the controller executes a command, after first being initialized with ... The other thing to notice is that the OrderController inherits from BaseController. BaseController is actually an adapter that implements an IViewRenderer interface.

          public abstract class 
          BaseController : Controller, IViewRenderer { public
void Render< TypeToBindToView >( IView view,
TypeToBindToView viewData ) { RenderView( view.Name( ), viewData ); } }

The OrderIndexCommand is initialized with an IViewRenderer.

          public class 
          OrderIndexCommand : IOrderIndexCommand { private IViewRenderer viewEngine; private
readonly IOrderTasks task; public OrderIndexCommand( IOrderTasks task
) { this.task = task; } public
void InitializeWith( IViewRenderer engineToRenderViews
) { viewEngine = engineToRenderViews; } public void Execute(
) { viewEngine.Render( ControllerViews.Order.Index,
task.RetrieveAllProtocols( ) ); } }

This month I've been going pretty hard core about learning ASP.NET and I was having a lot of difficulty with playing with the ASPX view engine. I'm already fairly familiar with HTML and CSS, but now I have to learn these new ASP.NET controls? Why can't I just stick to the HTML and CSS I know and enjoy working with?

Well it turns out I can... I don't need to learn about the complex data binding of a GridView or how an ASP:TextBox converts to a plain ol' input tag wrapped in span tags. I've been heavily studying the work from the project we worked on during the Nothin' But .NET boot camp and reading up on the MSDN documentation on inlining aspx.

I like it... C'mon doesn't this....

          <
          h1
          >Available
Slips</h1><table> <thead> <tr> <td>Location
Name</td> <td>Dock
Name</td> <td>Slip
Width</td> <td>Slip
Length</td> </tr> </thead><%foreach ( SlipDisplayDTO item inViewLuggage.ClaimFor(ViewLuggageTickets.AvailableSlips)
) {%> <tr> <td><%= item.LocationName %></td> <td> <ahref='<%=
WebViews.DockView.Name( ) %>?<%=
PayloadKeys.DockId %>=<%=
item.DockId %>'> <%= item.DockName %> </a> </td> <td><%= item.Width %></td> <td><%= item.Length %></td></tr> <% } %></table>

Seem a lot more readable then this...

          <
          asp
          :
          Repeater
          ID
          ="uxSlipsRepeater"
          runat
          ="server">
<
          HeaderTemplate
          >
<
          table
          >
<
          thead
          > 
          <
          tr
          > 
          <
          td
          >Dock
Name</td> <td>Slip
Width</td> <td>Slip
Length</td> </tr>
</thead>
</HeaderTemplate>
<ItemTemplate> <tr> <td>
<ahref='DockView.aspx?<%=
PayLoadKeys.DockId %>=<%#
((SlipDisplayDTO)Container.DataItem).DockId %>'> <%#Transform.From(Container.DataItem).AndConvertItToAn<SlipDisplayDTO>().DockName %> </a> </td> <td><%#Transform.From(Container.DataItem).AndConvertItToAn<SlipDisplayDTO>().Width %></td> <td><%#Transform.From(Container.DataItem).AndConvertItToAn<SlipDisplayDTO>().Length %></td> </tr>
</ItemTemplate>
<FooterTemplate>
</table>
</FooterTemplate>
</asp:Repeater>

The extra asp namespaces appended to all the controls just seem like noise. The explicit casting from Container.DataItem to the type actually contained seems like extra work. I suppose you could write all this out in an item data bound event handler. But it just looks like noise, noise noise... Then when you actually look at the HTML that's spit out it loaded with more noise...

For example:

          <
          input
          name
          ="ctl00$ContentPlaceHolder2$uxUserNameTextBox"
          type
          ="text"
          id
          ="ctl00_ContentPlaceHolder2_uxUserNameTextBox"
          />
        

Versus:

          <
          input
          name
          ="uxUserNameTextBox"
          type
          ="text"
          />
        

Well all of this can be avoided. But you're going to have to get just a little bit deeper, and here's how. Everything you need to know is in HttpContext. Yup!

Instead of dropping an ASP:TextBox on the page try an input element and parse out the value in the input element from the HttpContext.Current.Request.Params. This is a NameValueCollection that has all the Http Headers that were sent along the trip to the server AKA The Payload.

For my current school assignment I'm currently flushing out the concept of an HttpGateway, where all traffic comes in and all traffic goes out. Currently this is just wrapping and HttpContext but with an interface that works better for me as a client of it. I don't need to see everything available in the HttpContext (which is a lot!).

Next up, take advantage of the HttpContext.Items collection. This is a collection of objects which you can load up with extra information to pass on down the pipeline. Consider the concept of view luggage, where luggage is issued a ticket when you drop it off. You can then claim that luggage using the same luggage ticket.

What does this mean, you can have your presenters, controllers, commands (whatever) drop off luggage to be carried to the view. You can then have your views claim that luggage with the luggage ticket. (Take a look back at the first bit of HTML markup in this post.)

The HttpContext.Items collection is a dictionary for objects. Using strongly typed luggage tickets you can make that the key, and the actual luggage the value to store in the items collection. The HttpContext then becomes the airplane, carrier or transporter that hauls your luggage from your presenter, controller, command (whatever) to the view.

For the quick and dirty here's the code that describes what I'm talking about:

          public
          class
          ViewLuggageTransporter<
Luggage > : IViewLuggageTransporter<
Luggage > { public ViewLuggageTransporter( IViewLuggageTicket<
Luggage > key ) : this( key, HttpContext.Current.Items
) {} private ViewLuggageTransporter( IViewLuggageTicket<
Luggage > key, IDictionary items )
{ _ticket = key; _items = items; } public Luggage
Value() { foreach ( DictionaryEntry entry in _items
) { if ( entry.Key.Equals( _ticket ) ) { return (
Luggage )entry.Value; } } returndefault(
Luggage ); } publicvoid Add(
Luggage value ) { _items.Add( _ticket, value ); } privatereadonlyIViewLuggageTicket<
Luggage > _ticket; privatereadonlyIDictionary _items;
} publicclassViewLuggage { publicstaticIViewLuggageTransporter<
T > TransporterFor< T >( IViewLuggageTicket<
T > ticket ) { returnnewViewLuggageTransporter<
T >( ticket ); } publicstatic T
ClaimFor< T >( IViewLuggageTicket<
T > ticket ) { returnnewViewLuggageTransporter<
T >( ticket ).Value( ); } }

To parse out the value submitted in a request you can create mappers to parse out the values for each control. In the code below each of the string literals prefixed with a "ux" represents the name of the html control that was on the page.

          public
          class
          UpdateRegistrationPresentationMapper : IUpdateRegistrationPresentationMapper { publicUpdateCustomerRegistrationDTO MapFrom( IHttpRequest input
) { returnnewUpdateCustomerRegistrationDTO(
input.ParsePayloadFor( PayloadKeys.CustomerId
), input.ParsePayloadFor( PayloadKeys.For( "uxUserNameTextBox" )
), input.ParsePayloadFor( PayloadKeys.For( "uxPasswordTextBox" )
), input.ParsePayloadFor( PayloadKeys.For( "uxFirstNameTextBox" )
), input.ParsePayloadFor( PayloadKeys.For( "uxLastNameTextBox" )
), input.ParsePayloadFor( PayloadKeys.For( "uxPhoneNumberTextBox" )
), input.ParsePayloadFor( PayloadKeys.For( "uxCityTextBox" )
) ); } }

For an even sweeter example check out the source code for the NothinButDotNetStore.

Next up, figuring out a cleaner way to implement authorization and authentication without having to rely on the FormsAuthentication class. So far my spiking of Forms Auth looks something like the code below... *Please do not use the code below. I was just trying to understand how forms auth works and this is not a great example of how you should use it.

          public
          void AuthenticateHttpRequest(
) { HttpCookie cookie = GetCookieFrom( HttpContext.Current
); if ( null !=
cookie ) { BindPrincipalToThreadUsing( _mapper.MapFrom( FormsAuthentication.Decrypt(
cookie.Value ) ) ); } } privateHttpCookie GetCookieFrom( HttpContext context
) { return context.Request.Cookies[ FormsAuthentication.FormsCookieName
]; } privatevoid BindPrincipalToThreadUsing( CustomerCookieCredentials credentials
) { IIdentity identity = newCustomerIdentity(
credentials.Username, credentials.Username ); HttpContext.Current.User
= newGenericPrincipal(
identity, newstring[]
{"customer"} ); } privatevoid AddAuthenticationTicket(
) { FormsAuthenticationTicket ticket = newFormsAuthenticationTicket(
1, "mo", DateTime.Now, DateTime.Now.AddMinutes(
20 ), false, "2" ); string cookieValue
= FormsAuthentication.Encrypt( ticket
); HttpContext current = HttpContext.Current;
current.Response.Cookies.Add( newHttpCookie( FormsAuthentication.FormsCookieName,
cookieValue ) ); IIdentity identity = newCustomerIdentity( "mo", "2" );
current.User = newGenericPrincipal(
identity, newstring[]
{"customer"} ); }