Boy Scout:  “Leave thing better than you found them”

Marine: “Get in, get out, leave no trace behind.”

Sounds simple right?  So where does this apply?  Starting with the Marine.  I more frequently use this when dealing with someone else’s code, or something I just need to hack out real quick.  Often you don’t plan on maintaining the code, probably won’t own it, or you are just following the given pattern that is already established in the code – no matter how bad it is.  Typically you are just trying to get in and out without your name being attached.  You will also hear the adage “if it ain’t broke don’t fix it” commonly among staunch practitioners.  You can maintain code like this for a while, but if used too often it will come back to haunt you.  Each feature becomes harder to add, unexpected behaviors crop up, and performance problems creep in.

Now the Boy Scout.  You are adding a feature and find a mess.  The code is working, but is very unmaintainable.  Instead of just adding your feature, you tear the code apart and refactor the daylights out of the code.  Once complete and all is in order, then you add your feature.  It took you three times longer than expected to get the feature added, but you might be saving time in the future, assuming you will need to work with the code again.  Unfortunately, it is also very possible to get over your head in a hurry.  It would be great to have some unit tests to fall back on in this situation … but I haven’t seen that yet.  A good thing to do before you start a boy scout trip is to warn people where you are going, how long you’ll be there, and when to send for help.

Pointers

Now, lets not get too far ahead of ourselves here, there is absolutely a time and place for each approach.  It should also not be too hard to understand which is correct – but I’ll give some guidance anyway.  Here are some points.

1. If the code in question will be rarely used by one guy in the basement and doesn’t own a gun, marine mission till the cows come home.
2. If the code is non-critical, proof of concept, spike, or the like and can get everything done in less than 4 hours, marine mission.
3. If you are a consultant brought in to add one feature and supplement a team with a strange style but is currently working for them, marine mission.  Otherwise you will be “that guy”, meaning the one that didn’t fit in.  Sometime it pays to just go with the flow.
4. If the code is critical path, a essential web page seen by every customer you have: Boy Scout, and continue to Boy Scout.
5. If the code is already a buggy mess, the customers hate you, your product, and your car – role up your sleeves and get to work.

End result, either approach can get you in trouble when used inappropriately.  You need sound judgment to figure this out.  But then again, if software development was easy everyone would do it.

BTW: if you are using Entity Framework you are in the same boat.

So the question is, what to do with that last 10-20% that you need performance on?  Previously I had gone straight to Ado.Net, or used my own FluentAdo project.  But a few new projects have dropped in on the scene and it was time to take a look.

Let’s start off with some requirements:

1. Don’t be a pain to setup.
2. Don’t hork up my domain model (I have NHibernate for that).  POCO preferred.
3. Be able handle multiple result sets (something NHibernate does not do well)
4. Preference executing raw sql, not an api. 

I don’t need:
1. A custom query api for constructing sql.
2. Change tracking
3. Caching
4. Lazy Loading
5. Automatically loading child objects

Basically, be simple, be light, be fast, don’t be another NHibernate. 

Now the Contenders:

• Dapper
• Simple.Data
• Massive

Dapper

Dapper is my current favorite.  I deals with POCO objects, setup is very simple, very little overhead and ceremony.  That said, it is probably the rawest for dealing with sprocs.  But for a bare metal way of loading domain objects, this guy is hard to beat.

Here is a sample query:

var customer = _connection.Query<Customer>(
    "select * from dbo.Customers where CustomerId = @id",
    new {id = 1})
    .FirstOrDefault();

Basically, Dapper handles all of my requirements with ease.  I almost forgot to mention, Dapper is compatible with .Net 4.0 and 3.5.   That is a huge win for me.  Plus, the guys on Stack Overflow are using it, which makes for an easy “sell” to my management team.

 

Simple.Data

Simple.Data is also very interesting.  It makes extensive use of .net 4.0 and the dynamic.  Simple.Data is fairly ORM’ish, in that it seems to scan your database schema and dynamically add methods for retrieving data.  But it still uses POCO classes so I am good with that.

Here is a sample query:

var db = Database.Open();
var customer = db.Customers.FindByCustomerId(1);

To get that to work I defined the customer class with a CustomerID…and that is it.  Dapper came up with the FindByCustomerId part.  It also adds stored procs as well, so if I have a sproc called “GetCustomers”, I can call:

db.GetCustomers()

It is just scary what is going on here.  Granted there is a down-side to this system – albiet minor.  There is a bit of overhead while Simple.Data scans your database schema and gets setup.

Verdict: I don’t mind Simple.Data, but the .Net 4.0 only part is a problem, plus it strays a bit into becoming a ORM – a bit too much API, but nothing obnoxious.

Massive

I should have known how this one would turn out ahead of time, but I really didn’t want to believe it.  When I was young and foolish I was a SubSonic guy.  Truth is, I read Rob Connery’s blog religiously.  But I moved passed SubSonic and onto NHibernate and never looked back.  Heck, I moved passed Active Record and onto Repository Pattern.  (Since then I’ve moved on again to Query/Command Pattern, but another time for that).

First off, Massive horks up my domain model.  Each entity has to inherit from DynamicModel.  So before my model looked like this:

class Customer
{
    public int CustomerId { get; set; }
    public string Name { get; set; }
    public string Address { get; set; }
}

Now, Massive-fied:

class Customer: DynamicModel
{
    public Customer(): base("Default")
    {
        TableName = "Customers";
        PrimaryKeyField = "CustomerId";
    }

    public int CustomerId { get; set; }
    public string Name { get; set; }
    public string Address { get; set; }
}

And that “Default” in there, that is the name of my connection string.  Wonderful.  Also, because my table names are plural, I have to specify the name of my table for them in EVERY SINGLE CLASS.

Now, how to query:

var tbl = new Customer();
var customer = tbl.Single(1);

Smack-dab, back to Active Record.

Also, I didn’t see anything on how to parse multiple result sets.

Go to Rob’s site and you will see more samples.  Needless to say, it is off my list.  Granted, Massive is still much less overhead than NHibernate and Entity framework, but there is too much API there for me, too much setup, I don’t get my POCOs, etc.

I did just that.  I created an IPhone/IPad app called Agile Cards.  You can read up on it if you like.  Agile Cards is your basic card estimation app for the IPhone.  Real original, I know.  I think my competition is about a dozen other apps.  The only thing Agile Cards does that the others do not (that I know of) is use an IPad as a server.  This is optional of course.  So if you have several IPhones and an IPad you can have a digitally dynamic Scrum Estimation.

So what was I thinking?  I was thinking I needed practice.

I knew what I wanted to practice, so I thought up an app to do that with.  Now the great thing about the App Stores (for Apple, Android, and WinPhone 7), is that you can “easily” take these little apps that you are writing and sell them.  I’ve had dozens of apps that I’ve done for exactly the same purpose (to learn), but never had an easy route for selling them.  And setting up an online store is just a big pain as far as I’m concerned.

But I put easily in quotes up there.  There are a few caveats to my statement above.  I had a designer that wanted to do some more IPhone designing.  I’ve helped him with apps as well, so he was happy to help out.  If  you are going to go onto an app store, you will/should spend more time on user experience than you normally would, especially if you were just writing the app for yourself.

There is also the hassle of dealing with the app store requirements.  You need icons, splash screens, verbiage (which I kind of suck at), a web site, screen shots, email addresses, etc.  I even setup a Google Voice account for it.   All this for a free app?  (OK, there are ad, but free none the less).

What was I thinking?  I was thinking I also needed the practice of finishing an app.

There is nothing wrong with starting an app and throwing it away, or just stopping when you don’t need to go any further.  You end up with a program with a few quirks (bugs) that never get fixed, but you are probably the only person using it anyway.  That is fine.  But every now and then you need to FINISH something.  By FINISH, I mean shipping quality.  Shipping quality is hard btw.  It takes more time.  You need other people looking at things.

This is to remind you that software can be hard.  We deal with details, lots of them.  Selling software to other people means dealing with even more details.  It is good to do every now and then.  On your own.

So what was I thinking?  I thought it sounded like fun.

And by fun, like running a marathon half prepared fun.  BTW: I never did get to the “In app purchasing” bit.   I guess that can be next time.  It was to remove the ads.  I never have released an app with every single feature I ever wanted in it.

The book, Brain Rules by John Medina, is about the brain and what is actually know about.  I like the author’s criteria for what went in the book.  He called it the “Cranky Scientist Rule.”  Nothing is in the book that hasn’t been published in a scientific journal, peer reviewed, and duplicated by someone else.  I liked that as well.

Each chapter, and there are 12 of them, are about what the brain needs, and how best to give the brain what it needs.  There are chapters specific to Sleep, Stress, Short term memory, long term memory, and gender.  There are few absolutes in the book (except multitasking, he says you can’t do it and wants to ban texting in cars – I’ll grant him that one), but LOTS of pointers.  Also, there are plenty of asides where he talks about actual people with interesting conditions you should really hope you don’t get (but probably wouldn’t notice if you did).

And for a book on the brain, it is not dry at all.  The Author is a VERY effective writer, and judging from his credentials, probably an excellent teacher as well.  If you have a few minutes, I highly recommend checking out his web site: BrainRules.com and watch some of his videos.

Check out the book as well at amazon.

First, lets think about what the view should be doing – in a single responsibility sort of way: turn data into html.  That right there rules out several options.  No retrieving data, no extra data transformations.  Just turn some data into html.  And frankly, that is complicated enough.  So a side goal that I strive for is to create a markup page (the aspx) that is similar to the desired html output.  The main reason for that side goal is to make double checking the output that much easier.  I want to see a ‘div’ in my markup, and have a reasonable idea where that ‘div’ will show up in the html.

1. Keep as much code out of your views as you can.

Don’t make this rule overly simplistic.  Some code belongs in the view.  A ‘for’ loop to create a table, a simple ‘if’ block to show administrator functionality, stuff like that.  But you shouldn’t be having to specify the DateTime format, or string parsing.  That is what the ViewModels should do for you.  Rule of thumb, if you see a block where there is more C# than HTML, you probably did it wrong.

I will also extend this rule to JavaScript as well.  I’ve talked about the why JavaScript should not be in the views before, so this should not be a shock.  JavaScript belong in separate files.  Period.

2. Make Views typed.

This is true for all views where you have to pass data from the controller to the view.  Make a View Model for the view and pass data via that model.  This opens up a whole host of better patterns for you, like typed HtmlHelpers.  As a result, it is VERY rare that I will share a view model between views, or even Controller Actions.  I make separate models for GET, POST, and DELETE.  I guess my view is, the more the merrier.

3.   Make the View Models specific to the needs of the view.

OK, this isn’t actually a View best practice, but it is highly related.  If you try to keep the model for the view too generic, you end up with a lot of logic in the view to transpose the data into something useful.  The key point is that the data in the model serves the view, so all of the work to get the data into the correct format should be done when putting the data into  the model.  I will often take this to the point where the model will give html elements in the view their CSS classes.  So that means I have more than data from the database in the views.

Side note: when it comes to populating View Models with data specific for the View, AutoMapper rocks!  That is all.

4.  Custom Html Helpers are wonderful things

It is remarkably simple to create your own Html Helper, and once you get the hang of them they are beautiful.  They are wonderful little ways to encapsulate a small amount of logic so you can get it out of the aspx view.  Use them to encapsulate small amounts of code you need in various place through the project.

Another little “trick” I will use from time to time to create custom models just for a html helper (passed in via the view’s view model).  I have a few places where I need to change the markup because of the browser being used…so I create a custom helper that can detect the browser.

5. Standard HTML Helpers are great, but remember html

The key point I’m trying to make here is to become familiar with the output of the standard HTML helpers.  While the helpers can be great, they have their warts (anything having to do with an attribute name/value is a bit ugly).  Sometimes it is easier to swap them out with the standard html (especially with inputs) to get the exact output you want.  As a bonus, it is easier for the next guy coming in to figure out what you were after.   Currently, I’d say I use the helpers about 50% of the time over raw HTML.

Now, typing the html, or the helper, still kind of stinks.  You have to type the same code over and over.  Take a look at what Zen-Coding does.  You can do the same thing with ReSharper Templates or Visual Studio snippets…or just install one of the ReSharper or Visual Studio pluggins.  But beyond that, there is an art to customizing Visual Studio that you should learn.

6. Wrap all links in Url.Content and Url.Action

You have a web app.  You have to navigate between pages, call web services, link in javascript and CSS.  That is just what we do.  All of those links should be wrapped in Url.Content or Url.Action helpers.   The problem that is easy to run into is you move from development to test and the base url for your application changes.  You were testing at http://localhost:898989/ , and now you are deployed to http://myserver/myapp/  and a whole lot of urls just stopped working.  Url.Content and Url.Action are supposed to fix that.  That is why you use them.

7.  Get to know Partial Views for Ajax calls.

Partial views are actually just views that don’t have master pages and the html/body tag sections.  Partials can be executed in a multitude of ways, not just from inside a view on the server, but also from Javascript on the browser. JQuery also has a wonderful little method called $.load that will call a url, take the html that is returned, and slap it into the page.  This can greatly simplify a lot of behaviors.

I subtle little trick I sometimes do with this this is to wrap a section of code that takes a long time to load in a partial.  I will then call that partial into my page AFTER is has loaded on the browser (using the JavaScript function setTimeout to call the $.load ).  Now I get  a page that loads faster, but still has all of the data it needs.

8. Make the Master page work for you.

It isn’t that there is something inherently wrong with the existing master page that you get when you create a new Asp.net MVC project.  Typically it is 80% of what you would want.  But, as soon as I know what my general page is supposed to look like, I rip right into the Master Page.   Also keep in mind that you can nest Master Pages as well.

9. Think about what a designer would want.

Even if you don’t have one.  This is just a general pattern I try to get into.  I think about a designer as someone that can take raw html, add some css and images and make my work look a LOT better.    This means I use the raw html whenever possible, I write my JavaScript click handler so they will work with buttons or links (hint: always return false — and why haven’t I written a JQuery plugin for this yet?).

10.  Version your css and JavaScript

This is actually getting into my next blog post, but figure out a way to version your JavaScript and CSS.  This really isn’t MVC specific, you should do this in almost any project.  The key reason is to help you with a browser’s cache.  You know you have a problem when the first thing someone tells you, when asking for help, is that they cleared their cache already.   My thought on this is your web app’s dll should have a version number, set the project to auto version, and then pop that onto the end of the css/javascript file call.  So it might look like this:  ”http://myapp/…/file.css?version=1.0.0.256″.   In my sample code, when in development I stick a timestamp on the file in the same way.

OK, 10 rules is quite enough (I didn’t even think I would get that many).   To the american’s reading this: Happy Independence Day.

I was going to talk to some of my fellow developers about a couple of database issues.  The response was, “you said the ‘D’ word.  Now, we are an NHibernate/Microsoft SQL Server shop (or, Fluent NHibernate), and we rarely have to think about think about database architecture.  Heck, up till a month ago I don’t think we had to do any native SQL queries at all.  Currently, I don’t think we have any stored procs at all.  In my book, all of that is a good thing.  You can also chalk one up to Microsoft SQL Server in this one, our system has grown a lot and performance has remained pretty darn stable.

And lets be frank, I love this – most of the time.  Linq To NHibernate queries, Fluent NHibernate, and the like all make for a very enjoyable experience for developing against a database.  I would say that the vast majority of our querying needs are met with no further issues.  I certainly don’t want to go back to a stored proc world. 

That said, I don’t like using our ORM as an excuse to not talk about database issues or SQL issues.  If you are using a particular data storage technology, it still behooves you to know as much about it as possible.  Otherwise, when you get to a point where you need to know about what is going on will be too late.  Lets be frank here, no ORM will handle all of you query needs.  At best we are talking 90%, sometimes only 80%, for a typical application.  At some point you either have to go to the metal, or you end up coding things in a very strange way.

So here is the main point, as long as Relational Databases continue to be the “right answer” for business data storage, you need to learn database theory and SQL.  You might not need to know SQL as well as your native C#, Ruby, or other main language.  But that is not an excuse for not being comfortable with left outer joins, third normal form, and indexing.

Then the hands started raising.  Quickly, I might add.  I had to explain myself.  Yes, JavaScript goes at the bottom of your page.  Yes, I realize that we were all taught, back in the day, that JavaScript’s true home was in the <head> element.  In fact, many sample pages still show JavaScript at the top.  But we probably learned that ten years ago, you have to think a few things have changed…except IE6 – that sucker is going to live forever!  Anyway, I’m not the type that like to stand up in a crowd and say “everything you, and everyone you know, is doing is wrong” (I’m not that smart).  And if I do, I want to come with some substantial proof.

To start, where does the w3c say the SCRIPT element is supposed to go?  If you read the document in the link, SCRIPT can live in either the HEAD or the BODY elements. So technically, both places are legal.  I am stating this so that no one come back and tells me I’m breaking any fundamental web rules.  If the w3c says it is ok, then it is ok darn it.

But why the bottom of the page? 

That one is slightly harder to explain.  But here are the basics:  when a browser loads a document there are only so many thread for processing the document and download all the other crap that you put on the page so it pops (so, images and css, not to mention the bagillion font tags that Word likes to put in html).  There is also an unwritten rule that JavaScript should enhance the page after it is loaded.  So any time the browser spends parsing JavaScript is time it could be using to make the page look right.  Also, with some browsers, when the browser is loading JavaScript, ALL OTHER ACTIVITY STOPS.  Nothing else is downloaded, the browser is at a standstill until all the script is parsed – and you know how fast IE is at JavaScript.

Lets be clear about this “rule”.  I did not make this up.  But there are other ways around the performance penalty, you can also defer load your JavaScript.  Also, putting all of the JavaScript into a single, external file is a great idea.  With a external file you get the added benefit of the JavaScript file being cached by the browser (Note: great for the user – pain for your tester.  Repeat after me, “CLEAR YOUR CACHE” often when testing).

OK, so let us review.

But how bad is this?

That is a fair question as well.  Truthfully, it depends.  I know that is my stock answer, but I’m talking about how much this will affect the user.  It could be nothing.  But if you have a lot of JavaScript on the page, it could be significant.   Potentially it could be as annoying as a blink tag.  Even worse it might be on par with ESPN and their auto-playing videos.   But, if we are talking about 10-20 lines of script, there could be no change at all in render time. I will say this, by moving the script to the bottom of the page I have taken pages that were not usable for 10 seconds, improved it to moments (the page had a LOT of JavaScript…and it was a very noble cause).

What else should I be doing that I’m not?

This one is easy.  Run all of your pages through YSlow and PageSpeed (you need FireFox and Firebug installed for this) and find out.  Also, you don’t have to be perfect as far as these tools are concerned.  Some of the rule are probably not practical either (the “You should be using a CDN for images” rule comes to mind).  But it is good to know where you can improve.  PageSpeed has a number of really nice tools as well.  It will return you properly sized images, and compressed CSS and JavaScript if you ask it.

Here is the problem, as I see it:  as an MVC project gets large, keeping all of the necessary pieces and parts for a set of controller actions straight can get a bit daunting.  I’ve ended up with duplicate folder structures in views and models, which can make navigation a pain.

To make a new Area, simply right-click anywhere in you MVC project, Add->Area.  As I said, you can do this from anywhere in the project structure, but the Areas are created in a new “Areas” folder.  When you name the Area, a new folder is created with the Areas name as well.

Once created you should see all the familiar Controllers, Models, and Views folders (all blank).  In addition to that, you will see an <name>AreaRegistration.cs file.  This inherits from AreaRegistration, and this is where any new Routes go.  In the file is a prebuilt route that should look similar to this:

   1: context.MapRoute(

   2:     "test1_default",

   3:     "test1/{controller}/{action}/{id}",

   4:     new { action = "Index", id = UrlParameter.Optional }

   5: );

So a url to the area would include /test1/ (name of my Area) in the path.  That would be good if you had multiple controllers with the same name, but if you don’t, just take out the “test1” and you won’t need it in the path.

Also, if you leave Area name in the route, you will have a little more work to, here is what one of mine looked like:  <%=Html.ActionLink("test", "Index", "test1/TestArea") %>.  But it turns out this is more correct:

<%=Html.ActionLink("test", "Index", "TestArea", new { area="Test1"}, new {}) %>

This also mean that any controller actions you want to link to outside if Area needs to include a blank area in the link, like this:

<%=Html.ActionLink("Home", "Index", "Home", new { area=""}, new {}) %>

In case you are wondering, the first object in the area is for route values, the second is for html attributes.

So the downside of using Areas is that you could complicate your routing in a hurry.  Plus it does not look like the Html helpers are there to lend you a hand either.  It is very doable, just annoying.  Of course, the easy fix is to remove the Area name from the route and move on.  That should be ok so long as you do not have two controllers with the same name.

So are Areas a compelling feature? I think so.  Plus, the larger the site, the more compelling Areas can become.  For smaller sites, probably not.  But I would not say no either.

My first thought was “Crap, this is going to be rough”.  Mainly I was still thinking of my time trying to test Code Behind in Asp.Net WebForms.  I had to smack myself a few times after I remembered that the Controller base class is an abstract type.  Reality is that a Controller doesn’t have to be any harder to test than any other service class.  It isn’t like inheriting from Page (Asp.Net WebForms).

Not that my code did not have some lingering issues.  Like: why did I have something in my Controller Action that would require testing in the first place?  I hate having much logic at all in my Actions.  Get input, send it off for processing (logic), go somewhere.   That should be about it – unless you have to go to different places depending on what is returned.  Now, I want some tests.

Anyway, now back to your regularly scheduled program.