.net and other musings

Ben Lovell, an agile developer living in the UK.

Category: MVC

MVC Storefront

Rob Conery has been posting a series of screencasts featuring the development of an ASP.NET MVC based product catalogue. This is being carried out in a “TDD” like fashion. The interesting difference between his posts and mine (apart from the obvious fact that I’m lazy and haven’t screencasted… yet) is that he starts from the bottom of the stack and works upwards towards the UI where as I do the opposite.

Its interesting contrasting the two approaches not to mention the differences between the ASP.NET MVC framework and Castle Monorail way of getting things done.

Incremental development with Monorail: Part Three

Part One
Part Two

In the last instalment we finished up with a suite of passing tests. However, we’ve yet to produce anything remotely usable so lets continue by reaching down further and driving out our services/persistence. We’ll start by writing the following test:

23

We’ve meddled with our test setup a little to introduce the MockRepository for mocking out our PostController’s new dependency on the IBlogPostService. Our test now calls the AddPost method on our service interface and sets up the resulting AddPostResponseDto. Running the test produces a bunch of compiler whinging so we best implement the newly introduced bits:

24

25 

26

These are the only changes and additions we’ve made in order for the tests to compile and run. Running our test now produces the following result:

27

As we’ve yet to modify the PostController.Save(…) call to include a call the newly introduced IBlogPostService dependency. Lets go ahead and do this now:

28

We’ve now included the call to our newly introduced service and we set the responseMessage if the response is signaled as successful. Lets run our test now:

29

It works, ship it! Actually no, again we’re pretty low on actual functionality right now. Remember we’ve yet to actually drive out any implementation of the IBlogPostService interface as yet and I expect that the acceptance test will fail horribly since we didn’t wire up the necessary container configuration either. Lets go ahead and run the whole test suite and see what gives:

30

In the brief moments the browser appears during the test we can see the following:

31

Hmm, as I predicted earlier our application fails to run due to the lack of proper container configuration. Before we can do this we need to implement the IBlogPostService interface somewhere. We need to write a failing test to begin our foray into the implementation of a BlogPostService:

32

Lets create the BlogPostService only performing the steps necessary to pass the test above:

33

Run the test:

34

Now we have a working BlogPostService we can now wire up our container configuration to pass the acceptance test:

35

Now running the full suite of tests produces the following:

36

Our tests pass!

That’s it for this post. I’ve checked in the latest changes to the repository. In the next post we’ll continue our efforts and begin to implement validation on our screen-bound DTO’s.

Google code hosted project: http://code.google.com/p/mr-blogengine/

MVC.NET

Unless you’ve been living under a rock for the last few days you will have noticed that the first CTP of the ASP.NET 3.5 extensions has now shipped. ScottGu has the lowdown as usual.

Given the extensibility of the framework, its not surprise that several interesting modifications/add-ins are cropping up. Hammett has dropped a pile of samples:

MvcExtensions: a class library project with all extensions developed including parameter binder support, Windsor integration and a NVelocity View Engine. I remember complaining about relying exclusively on inheritance to change behavior/add specializations. Looks like I’m not alone on this… To some things, a vertical approach is good enough, but not usually to frameworks. The inheritance scheme eventually will turn into hell in a complex project. I know as I been there.

RestSupport: Uri formats and a nice Respond To syntax inspired on the work from Chris Ortman/MonoRail.RestSupport.

UsingAR: self explanatory

UsingNVelocity: ditto.

Take a look at his blog post for more details and to download the samples here.

However the most traction award has to go to the open source MvcContrib project on Codeplex which will serve as a repository for all things MVC. MvcContrib has already taken contributions in the form of controller factories for the main container frameworks out there: Windsor, Spring.net and StructureMap.net and a Monorail style binder to aid conversion of a NameValueCollection (i.e. form or querystring) to an object graph.

I’ve been toying with MVC for a few hours in between real work and the one benefit which initially strikes me is nicer VS.net integration using the webform view engine. Full intellisense and type safety in the views is something sorely missing from Monorail (given that I use the NVelocity view engine there, not sure about the other view engines and what they provide).

A side-effect of using the MVC framework is that I’m finally getting to use all the cool 3.5 language features too.

The Day of Reckoning?

… OK perhaps not. Anyway, today is the supposed release date of the first CTP of the new Microsoft System.Web.MVC framework. As you’ve no doubt seen in previous posts this is a pretty big deal to me.

I’m putting the final touches on a fairly big project right now and have a smaller (internal) one lined up which would be a perfect candidate for testing out System.Web.MVC. Lets see how it stacks up against Monorail…

Microsoft MVC next week?

Some news if you haven’t read it elsewhere: the ASP.NET 3.5 extensions CTP is due for release at some point next week. My primary interest being MVC by far, then Astoria I guess.

I can’t wait to start fiddling with the MVC framework. Good work Microsoft!

Check out ScottGu’s post here for more information.

ASP.NET Development Landscape

With all the System.Web.Mvc goodness flying around at the moment, the Microsoft or nothing shops (you know, the ones that flat-out can’t adopt a technology unless it comes from the borg) might finally get a taste of how web development should be done. Unfortunately for the aforementioned reason, Monorail has never be an option for those developers.

The one thing that really excites me about MSMVC is the periphery of concepts that will be introduced by way of association: deep testability, SRP, DIP and SoC. Traditionally these practices aren’t promoted (or I might go so far as say easily achieved) heavily in the .NET technologies and frameworks coming out of Microsoft. As we’re focusing on ASP.NET at the moment, sure, they’re possible to adhere to whether you’re using ASP.NET in the presentation layer or not, but ASP.NET doesn’t promote them the same way the MVC framework will.

I can’t help but wonder how different the landscape might be now if MSMVC was released with .NET 1.0 instead of webforms?

Microsoft MVC Framework

Some of you may be aware of the ALT.net conference going on this weekend. I wasn’t particularly interested in a gathering of egos in mutual back-slapping, but I was interested in the announcement of the System.Web.MVC framework from Microsoft.

This has been on the cards for a while and had kinda been announced a while back by Scott Guthrie. Since then not much detail has been uncovered other than a one or two hires for the dev team (from what I’ve heard from my sources ;))

Jeffrey Palermo announced some of the technical details in this blog post, although light in actual substance, yet giving us more idea than anything released previously.

Some of the key things of note:

  • Testability: the key concern. Overcome by making everything virtual/behind interfaces and extension points abound.
  • Ability to plug-in to framework via aforementioned extension points. Gives us the ability to add extra view-engines a la Monorail.
  • Default view-engine implementation using ASPX without postback and viewstate pain.
  • Controllers can be resolved from a container i.e. Windsor, Spring.net etc.

A CTP is due towards the end of the year (Monorail will suffice just fine until, and probably far after then) and the framework is slated for release with VS2008 as an add-on to the general release.

Some of the things I’ll be interested in seeing are whether the following are supported:

  • Handling devices, i.e. sniffing user agent and providing different views. Something just recently provided in patch form to Monorail.
  • The MSMVC equivalent of Monorail’s ViewComponent concept.
  • Routing and URL rewriting support.
  • Monorail Helper equivalent.
  • AJAX support.

It has been mentioned that some of the plumbing may be used to reduce the Monorail codebase. Now that could be interesting…