Tales from the Evil Empire : MVC

Orchard team looking for a new developer

Bertrand Le Roy — Mon, 23 Nov 2009 19:24:19 GMT

My team is looking for a new full-time developer. The project is to build a completely new open-source CMS based on ASP.NET MVC 2. It’s a lot of fun :)

https://careers.microsoft.com/JobDetails.aspx?ss=&pg=0&so=&rw=1&jid=9434&jlang=EN

Walking the tight rope

Bertrand Le Roy — Thu, 27 Aug 2009 22:40:00 GMT

I think today is an appropriate time to write this post, as Rob Conery is leaving Microsoft tomorrow. “Who?”, you might ask. Rob is the author of the excellent MVC Storefront and Kona series where he explored the challenges in building an MVC-bound storefront application. I’ve been working with Rob for a few months on the continuation of that, which will be the subject of this post.

This is challenging for a number of reasons.

First, Rob’s are large shoes to fill (he’s a 12, I’m an 11). That’s fine, I’m just going to do things my way and try to have as much fun as possible (and communicate that if I can).

Second, the focus of the application has changed and that is a much more important challenge. Rob built this as a learning tool, as much for him as for his readers.

In the team that I’m now a part of, we have taken that Kona code as the basis to build something that will hopefully be more like a real world application. We are still very much in an exploratory mode (hence our attempts at migrating the application to NHibernate and SQLite) but our ultimate goal is to provide an application that people can download and build a business on, with a focus on simplicity and extensibility.

Fine, you may say, but why build something new instead of contributing to existing applications? Well, the very short answer is that we are also going to do that. One of the things we are already doing is to work with various application developers on reusing things like the plug-in engine and what sharing opportunities that brings.

But I can already hear some of you saying “oh so you’re not just building an application, what you’re really doing is building yet another framework”. To which I’m tempted to answer with another question: what do you mean “another”? Where is my Django-style application-level framework for ASP.NET? But that may sound like I’m downplaying the great efforts that many people are putting towards exactly that. I clearly am not. Actually, if you are working on something like that and we’re not already talking, I would love to know about it. I want to know how we can help.

A total n00b’s guide to migrating from a custom data layer to Nhibernate: getting started

Bertrand Le Roy — Mon, 17 Aug 2009 23:29:00 GMT

(Screencast can be found at the end of the post)

To be clear when I say “total n00b”, I’m not talking about you, dear reader, I’m talking about me. The last time I wrote any serious data access code was circa 2002. Since then, I got hired by the Evil Empire and started developing new tools to make it easier to build demos of Northwind master-details. I jest, I jest. Or do I?

So let me explain what I’m going to talk about in this and future related blog posts. We have this e-commerce application that Rob started and that we’re going to continue developing. Last time Rob touched the data access, he wanted to experiment with going back to less abstraction and to working directly with that interesting data-centric Domain Specific Language, you know, SQL. So he went ahead and played with that T4-driven DAL generator. It was interesting as an experiment, and Rob’s blog series is all about experimenting publicly, but let’s face it, that data access didn’t fly much farther than that. To be clear, I’m not saying that Rob was to blame for our sucky data access layer, but the truth is that we have had this franken-DAL from the nineties in the code for a few months now and it needs replacing. So what do we do?

First, we look around and find out what other people out there are doing. We could go for the Microsoft flavor of ORM, EF, but we’re not going to do that (at least not yet) and will instead go for the one that is the most widely used by the community as of today, and that is, I believe, NHibernate. The home page for the project itself can be found at http://nhforge.org and the best place to get started is probably the tutorial section of that site: http://nhforge.org/doc/nh/en/index.html#quickstart.

In this first post, I’ll just play with the library and try to get a list of products to display on a page. In future posts, I’ll look at the actual app and start migrating it. For this time, because I’m just trying to get to grips with a library I don’t know, it’s going to be quick and it’s going to be dirty. Definitely don’t take any of what you are about to see as best practices. Ever.

The first step is to add the NHibernate and dependencies to the project. The library can be downloaded from SourceForge (http://sourceforge.net/projects/nhibernate). Nhibernate is itself under LGPL but it comes with the following dependencies:

Antlr: a library to construct grammar parsers, interpreters, etc. typically for domain specific languages. It’s under a BSD license.
Iesi.Collections: a library that implements sets (collections with unique elements) and that doesn’t have a definite license. A comment from the author seems to implicate public domain.
Log4net: the leading logging library for .NET, licensed under Apache 2.0 and managed by the Apache Foundation.

You may not care too much about that, but your boss and his lawyer might… Technically, all you need to add to the project is a reference to the NHibernate dll and the others will follow.

Once the reference has been added to our project, we can start configuring. This can be done in a variety of manners but the easiest is to do it through web.config. The basic configuration for NHibernate consists in the connection string, the SQL dialect and the proxy factory to use. Because we don’t want to repeat ourselves and because I prefer my connection strings to live in the connection strings section of web.config, I’ll use a “connection.connection_string_name” setting instead of a “connection.connection_string” setting:

<hibernate-configuration xmlns="urn:nhibernate-configuration-2.2">
  <session-factory>
    <property name="connection.connection_string_name">
      KonaConnectionString
    </property>
    <property name="dialect">
      NHibernate.Dialect.MsSql2000Dialect
    </property>
    <property name="proxyfactory.factory_class">
      NHibernate.ByteCode.LinFu.ProxyFactoryFactory,
      NHibernate.ByteCode.LinFu
    </property>
  </session-factory>
</hibernate-configuration>

The proxy factory factory class stuff looks a little intimidating and a little over-architected from just looking at it (a factory factory? To create proxies?) but it’s not as bad as it looks. What this is doing is declaring what library to use to generate dynamic proxies for our data classes. It is a good thing that NHibernate is open to multiple providers here, and the good news is this is probably the first and last time you need to know about this. Just make a choice if you care (and know why you care), or use this one (licensed under LGPL) if you don’t.

But what is a dynamic proxy, you may ask? First and foremost, it is a proxy class that will be used in place of the POCO class that you will provide to represent your data. Its purpose is to intercept all calls into the object’s properties, both getters and setters, and to handle things like lazy loading. The dynamic aspect of it is that those proxy classes are dynamically generated, usually using Reflection.Emit. This means that until .NET 4.0 is here, using lazy loading in NHibernate will prevent the application from running in medium trust. More on that in future posts, but know that lazy loading is not mandatory and can easily be disabled from the mapping file.

The next thing to do is to grab the NHibernate configuration in order to create a session out of it. The configuration can be built from the web.config data like this:

var nhconfig = new NHibernate.Cfg.Configuration().Configure();

A session is the mediator between your code and Nhibernate. According to the documentation, it is a “short-lived object representing a conversation between the application and the persistent store”. Its lifetime is usually the same as the lifetime of the request. Here’s how you can create a session:

var session = nhconfig.BuildSessionFactory().OpenSession();

With all that we are pretty much set-up but we are still lacking any data. Let’s fix that and attempt our first mapping. I’m going to use a simplified version of the product database we have in the commerce app (which is none other than AdventureWorks). In there, I have a Products table that looks like this:

We don’t have to map everything in that table so we won’t (yet). Instead, we’ll create a simple and incomplete class to represent a product:

public class Product {
    public virtual string Sku { get; set; }
    public virtual Guid SiteID { get; set; }
    public virtual string Name { get; set; }
    public virtual double BasePrice { get; set; }
}

Notice how all fields are virtual here. This, again, is done so that a dynamic proxy class that overrides those properties can be created.

Now we have the O (object) and the R (relational), so let’s do the M. The mapping is an XML file that we’ll put next to our Product class:

<?xml version="1.0" encoding="utf-8" ?>
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2"
    namespace="Nhib.Models" assembly="Nhib">

  <class name="Product" table="Products">
    <id name="Sku">
      <column name="SKU" sql-type="nvarchar(50)" not-null="true"/>
      <generator class="uuid.hex" />
    </id>

    <property name="SiteID"/>
    <property name="Name">
      <column name="ProductName"/>
    </property>
    <property name="BasePrice" />
  </class>

</hibernate-mapping>

The mapping class is named like the Product class, with a “.hbm.xml” extension. It is also configured to build as an embedded resource so that Hibernate can reflect on it at runtime. This is done by setting the Build Action in the properties of the file in Project Explorer:

And we’re done as far as setup is concerned. Now all that remains to do is to actually query and display that data.

Because I’m just playing with the framework at this point, I’ll just query from the Index controller action:

var nhconfig = new NHibernate.Cfg.Configuration().Configure();
nhconfig.AddClass(typeof(Product));
using (var session = nhconfig.BuildSessionFactory().OpenSession()) {
    var query = session.CreateQuery("select p from Product as p");
    ViewData.Model = query.List<Product>();
}

UPDATE: Ayende is right to attract my attention to the fact that building a session factory is an expensive operation and so you should treat it as a singleton. In other words, create the factory once and store it in a static variable. For the sake of the simplicity of the example, I'm leaving the code above, but again, don't do this at home...

And finally, let’s render this from the view:

<ul>
<% foreach (var p in Model) { %>
    <li><%= Html.Encode(p.Name) %> - $<%= p.BasePrice %></li>
<% } %>
</ul>

The results look like this:

I hope this gives a good idea of how simple it is to get started with NHibernate, because it really is. I knew near to nothing about it and almost didn’t have to fight the framework to get it running. Seeing the first successful rendering on my very first CTRL+F5 was very encouraging.

In a future post, I’ll show how this applies to a real-world application and how we migrated such an application from its existing data layer to one that uses NHibernate.

The source code can be downloaded from here: NHibGettingStarted.zip (warning: all files provided under their respective licenses).

… and here’s the screencast:

Mocking indexer getters with Moq

Bertrand Le Roy — Thu, 16 Jul 2009 23:42:17 GMT

This is a follow-up on that other post: Mocking indexer setters with Moq.

So thanks to that post, we now know how to intercept the setting of a particular indexed property (in our example, an application variable) and set a local variable with the value that was set by the tested code.

Now if you want the application to return that same value when queried by the tested code, you also need to mock the indexer getter.

This operation is also not entirely trivial. Here’s how you do it: you do a SetupGet chained with a Returns with a lambda expression as the parameter:

mockHttpContext
    .SetupGet(c => c.Application["foo"])
    .Returns(() => (object)map);

That last point about using a lambda is pretty important. If you just use map as the parameter for Returns, Moq will hold on to a reference to whatever object map contained at the time the call to Returns is made. This might very well be null, if you started with the code in our previous setter example. If you use a lambda on the other hand, Moq will not hold on to the value of map but to the expression that returns the value of map. The execution is deferred. Now every time the tested code exercises that path, Moq will evaluate the expression, which will return the current value of map.

Also of interest, whereas we had to explicitly have an index parameter for the callback lambda in the case of the setter, Returns needs no such thing, and this example actually has little code that is specific to indexed properties. The trick about the lambda in the Returns in particular applies just as well to mocking getters for non-indexed properties.

Tell me what smells in WebForms as a view engine

Bertrand Le Roy — Mon, 13 Jul 2009 17:58:00 GMT

Don’t read too much into this, but I’d love to read your feedback on this. I’m compiling a list of stuff that smells in WebForms when used as a view engine in MVC.

Along the lines of:

Noisy page directives that are useless for MVC
runat=server
Page lifecycle

For once, you can let the inside troll take over :)

Mocking indexer setters with Moq

Bertrand Le Roy — Mon, 15 Jun 2009 22:27:52 GMT

I quite like MoQ because it makes sense for me. Shamefully, I’ve always had some trouble understanding test code that was using mocks built with other frameworks. With MoQ, I can just grok it for some reason. It’s just super-clear to me. It doesn’t mean I have any idea how it really works but for now I’m just happy with the magic.

Anyway, yesterday I wanted to check that a controller action was setting some Application variable (let’s not get into the debate on whether or not it should do that at all). Something like this:

application["foo"] = new Foo();

Now how do I enable the object to be set by the tested code? Well, that one is easy, I can use SetupSet on indexers just fine:

var mockHttpContext = new Mock<HttpContextBase>();
mockHttpContext.SetupSet(
    c => c.Application["foo"] = It.IsAny<object>());

This call tells the mock that it can accept to run code that attempts to set the “Foo” application variable with any object.

But now, what if I want to get a reference to that object from my test code in order to check the value of some of its properties?

Well, MoQ has a Callback method that you can hook to the result of any Setup call. The action that you provide it will be run whenever the setup code is called. The problem with that callback method is that its signature must match that of the setter exactly. Unfortunately, that signature is implicit. If you get it wrong, the test will fail more or less silently (it will just tell you setup failed with little details). To get this right, you need to know what the setter syntactic sugar compiles to, which kinda sucks, but the good news is that you only have to figure it out once, which I just spent some time doing for you (and for myself too, let’s be honest):

var mockHttpContext = new Mock<HttpContextBase>();
Foo map = null;
mockHttpContext
    .SetupSet(c => c.Application["foo"] = It.IsAny<object>())
    .Callback((string name, object m) => { map = (Foo)m; });

Because this is an indexer setter, the compiled code actually takes a name and a value, which is reflected by the signature of the callback lambda. We can now call into the code to test, knowing that when it sets our “Foo” application variable, the local “map” variable of the test code will get set. The test code can then party on the object and assert whatever it wants.

I hope this saves some time whoever is trying to do the same thing.

Some MIX talks

Bertrand Le Roy — Mon, 23 Mar 2009 04:14:22 GMT

Stephen Walther just published links to the video, slides and sample code for his Ajax talk at MIX09:

http://stephenwalther.com/blog/archive/2009/03/22/mix-slides-code-and-session-recording.aspx

It’s pretty cool to see all the work we put into Ajax this past year or so presented at MIX. This is a really nice presentation, like Stephen’s always are.

Another presentation I had lots of fun watching (not just because the speaker is making an incredible impression of me but also because I’ve been spending a good part of my time lately contributing to the application he’s showing) is Rob Conery’s. Rob is showing an interesting way to develop ASP.NET applications, aimed at ease of use and customization rather than architectural purity. Check it out, let me know what you think…

http://videos.visitmix.com/MIX09/T62F

ASP.NET 4.0 Roadmap talk available online

Bertrand Le Roy — Tue, 28 Oct 2008 22:09:26 GMT

Scott Hunter’s talk on the ASP.NET 4.0 roadmap (in which I’m doing a 10 minute demo) is available from Channel9:

http://channel9.msdn.com/pdc2008/PC20/

Going to California

Bertrand Le Roy — Wed, 22 Oct 2008 19:25:00 GMT

I’m flying to San Jose tonight for tomorrow’s OpenAjax Alliance face to face meeting, which Microsoft is hosting. On Friday, we are also hosting a new event that aims at establishing a dialogue between JavaScript library developers and Microsoft. We’ll have talks from the IE, Visual Studio and ASP.NET teams, as well as talks from members of the community. This should be very interesting.

Then I’ll be flying to L.A. for the PDC. If you’re going to be there and want to chat, feel free to drop me a note at bleroy at Microsoft.

I’ll be in the room during Stephen Walthers’ session on jQuery and ASP.NET on Tuesday from 5:15 to 6:30 (403AB).

I’ll also do a short demo in Scott Hunter’s talk on the ASP.NET 4.0 Roadmap on Monday from 1:45 to 3:00 (153).

Other sessions I’ll attend include Phil Haack’s MVC session (Monday, 3:30 in 153), Jeff King’s talk on Visual Studio Web Development Futures (Monday, 5:15 in 153), the panel talk on the future of programming languages (Wednesday 10:30 in 403AB), Frank Savage’s XNA Game Studio talk (Wednesday, 12:00 in 501B), Anders Heljsberg’s talk on C# (Wednesday 3:00 in 502A), Miguel de Icaza’s talk on Mono (Wednesday at 4:45 in 515B) and of course Stefan Schackow’s ASP.NET Cache Extensibility talk (Thursday 10:15 in 403B) which was the highest rated talk during our dry-run of the conference…

And of course, I’ll be on stage for my own talk on ASP.NET 4.0 AJAX on Thursday from 1:45 to 3:00 (Petree Hall CD), which will pretty much close the show. I’ll be building a small application using client templates, bindings, some jQuery and ADO.NET Data Services.

Using the Ajax Control Toolkit in ASP.NET MVC

Bertrand Le Roy — Mon, 25 Aug 2008 19:20:00 GMT

Stephen Walther has a pretty cool post on using the new file-only version of the Ajax Control Toolkit from an MVC application:

http://stephenwalther.com/blog/archive/2008/08/23/asp-net-mvc-tip-36-create-a-popup-calendar-helper.aspx

UPDATE: the problem with Stephen is that he writes quite fast. So pretty much in the time it took me to link to his first post, he wrote a second one, this time on using the AutoComplete behavior:

http://stephenwalther.com/blog/archive/2008/08/24/asp-net-mvc-tip-37-create-an-auto-complete-text-field.aspx