During the wireframing process of a recent project, we noticed some very repetitive behaviors of our system. The one that stuck out the most was a scenario from moving from a search screen to a details screen from software development firm. We started going through the code in our heads and figured it would look something like this:

  1. Verify that the requested entity exists
  2. If the entity does not exist, redirect back to the search screen; otherwise, render the details model

Before I get into the details of Fubu, let’s take a look at how we could implement this using the standard ASP.NET MVC approach:

This implementation is fairly clean but it shouldn’t be specific to the Vendors entity. I say that because we have a minimum of 15 other entities that all need the same functionality. We really didn’t want to have to copy/paste and change a couple of type params.

Wifi, Internet, Girl, Denied, Access, Network, Digital

Note:
The purpose of this post is not to focus on the details of ASP.NET MVC. This example is provided as a reference for readers that do not have any experience with FubuMVC. You can do some pretty neat tricks to get ASP.NET MVC to bend to your will. Check out Jimmy Bogard’s series on Dependency Injection in ASP.NET MVC.

Let’s take a step back and think about what we’re doing again: we want to render a details screen for a given entity. As I mentioned before, we have some simple rules to follow:

  1. Verify that the requested entity exists
  2. If the entity does not exist, redirect back to the search screen; otherwise, render the details model

That sounds pretty simple, right? Let’s make a “Coordinate” type of class that does exactly that:

There’s really nothing to this “action”. We’re deferring the responsibility of actually obtaining the entity to an IEntityService implementation and the mapping of the vendor to our details model is deferred to our IMappingRegistry and testing software. This makes it really easy for us to write some corresponding tests:

Now that we had a reusable class for providing details models, we needed to register a route for it against all of the entities that we wanted to render. We may not want to provide details screens for every single one of our entities, so we made a simple “matcher” that scans particular namespaces and filters our types that are specified during our configuration of our model. For every type that is matched by those filters, we register a new behavior chain:

Note:

This proved to be a little more challenging than we had originally anticipated because (at the time of this writing) FubuMVC’s configuration DSL currently does not have any direct support for manually registering generic ActionCalls.

And that’s it! The details of our model conventions are handled through our IEntityViewModelResolver interface. You can imagine having a solution structure like this:

  • Models
    • Vendors
      • VendorRequestModel
      • VendorDetailsModel

With that convention in place, enabling details screens is as simple as creating the model classes and dropping them in their respective namespaces in software developers company. Not only does that save a lot of time, it also removes the need to repeat yourself for every entity.

For anyone still curious about Fubu’s Configuration Model and their Behaviors, we will be making a few posts in the coming weeks to help you get started.

Startup, Whiteboard, Room, Indoors, Adult, Office

Using SQL Functions in NHibernate’s Criteria API

We recently began using NHibernate for all of our new projects and have had a wonderful time getting to know the ins and outs of the technology.  The Criteria API makes it very easy to build up complex queries and control exactly how the SQL is generated, a feature that we believe is severely lacking in Linq 2 SQL and software testing.  One of the handy features I discovered today is the SqlProjection which allows you to write a bit of SQL to optimize a query without writing too much SQL (because SQL in code is generally not good practice).

I used the SQLProjection to help retrieve users via the first initial of their last name.  In Linq you could just do this:

DataContext.Users.Where(u => u.LastName[0] >= startInitial && u.LastName[0] <= endInitial)

While I could have done the same clause in memory (or use Linq 2 NHibernate), that means I would have retrieved all of the users instead of just the small subset I was looking for.

Using the criteria API is a bit different and altogether provides a much nicer solution that lets SQL Server do the processing.  First, we’ll setup our Projection that will give us the last initial so we can create a restriction on it in the next step.

var lastInitialProjection = Projections.SqlProjection("LEFT(LOWER(LastName), 1) as LastInitial", new[] {"LastInitial"}, new[] {NHibernateUtil.String});

Next we can use a Restriction like you normally would except that instead of the property name as the first parameter, we will pass in our projection like this:

query.Add(Restrictions.Ge(lastInitialProjection, Char.ToLowerInvariant(startInitial)));

I found that this works well and gives you a fairly optimized SQL query. You will notice that it is setup to be case insensitive.  Also, please note that this method may not work outside of SQL Server and probably should be avoided if you are planning on switching database engines in the future.

Everyday Git Workflow

The ProAce team recently started using git for some of our new projects and so far we all really like it after we got over our initial hiccups.  The hardest part of the transition was a learning curve that was steep only because of the lack of clear documentation for how git is used on a daily basis in mobile application development services. There is a lot of help in getting yourself setup (especially on GitHub) but I found that once you have git going, how do you keep it going? 

After a few days of use one quickly develops some patterns that become standard, so I decided to make a workflow diagram for the team so that we all continue to use git the same way:

In this setup you will notice a remote named ‘proace.’  This is our main ProAce GitHub location, and the origin is a per-user fork of the main ProAce repository.  Please feel free to use this diagram as a reference on your own projects, you can download it as a PDF below.

 

Related Posts: