NHibernate WCF Error: HTTP request context being aborted by the server??

I’ve been ambivalent toward ORMs for quite some time now, but I’m really starting to dislike NHibernate in a special way.  My experience has been that ORMs lead to a lot of wasted time troubleshooting code problems that are really ORM problems.  Here’s one example.

I recently got this mysterious and unhelpful error message on an ASP.Net MVC3 web app that was pulling data via a WCF web service, which in turn was using NHibernate for persistence.

An error occurred while receiving the HTTP response to http://localhost:8080/JobsService/ws. This could be due to the service endpoint binding not using the HTTP protocol. This could also be due to an HTTP request context being aborted by the server (possibly due to the service shutting down). See server logs for more details.

Ok, my service endpoint was definitely using HTTP and none of that other stuff was happening either.  So what was the problem?  NHibernate lazy load proxies.

Let’s say I have a Company entity that contains a child collection of type List<Job> as shown in the diagram below.  So if we look at the Company entity, all of the fields (Name, State, City) exist in my data table, except for the Jobs.  Jobs represents a relation between my Company and Job tables and to get Job data NHibernate has to query the Job table.

At this point it’s important to note that I’m using NHibernate, all of my entity properties are virtual, and I have lazy loading enabled.  So what happens when I run a query to get a Company? What data does NHibernate populate?  It’s going to populate all of the data that’s in the Company table (Name, State, City) , but it’s not going to populate the Jobs collection.  It’s going replace that virtual property with a proxy that will execute a query to get Jobs only when that property is accessed. 

I actually think this lazy loading proxy technique is pretty neat and it’s technically impressive.  Unfortunately it’s also the root cause of a lot of application errors.

So the lazy loading proxy works great when we’re accessing an entity directly in our web app while it’s still has the context of the NHibernate session, but what happens when we try to return our Company over WCF and WCF tries to serialize that Jobs property that hasn’t been lazy loaded yet?  That’s right, you get the ambiguous error message above. 

The fix is simple.  You just need to eager load the Jobs. You can do this any number of ways.  Here’s how to do it in a criteria query.

return session.CreateCriteria<Company>()
            .Add(Restrictions.Eq("Id", _Id))
            .SetFetchMode("Jobs", FetchMode.Eager);

Now that we’re eager loading the Jobs there’s real data there instead of the lazy load proxy, WCF has no problem serializing the Jobs, and our mysterious ambiguous error goes away. 

So, I hope this saves someone a little time, and please remember, friends don’t let friends use ORMs.

The problem with ORMs

Over the last 8 years I’ve done a lot of thinking and experimenting with different persistence models. If you’d asked me 6 years ago what a persistence layer should look like I would have whole heartedly suggested an ORM like nHibernate.  Linq to SQL came along and initially looked promising but I quickly soured on it in favor of Entity Framework.  Then I actually tried to use Entity Framework in a production app and quickly found that in spite of the initial query writing efficiencies, it caused problems in other areas and the net result was that it didn’t save me any time at all but did add limitations and complexity to my app. 

So what was the problem?  As I spoke with more developers I started to hear the same complaints, even though some were using EF, some were using nHibernate, others were using LinqToSql.  I heard the problem stated best by a guy I met at the speaker’s dinner for the Rocky Mountain Tech Trifecta.  I can’t remember the guy’s name but his words stuck with me. I was telling him that I would never use EF again if the choice was up to me.  He said it’s not that he has a problem with Entity Framework, it’s that he’s done with ORMs.  I think that’s really the heart of it.  There’s a fundamental problem with ORM as a pattern.  It just doesn’t adequately solve the problem and it ads significant complexity and inefficiency to an application.

I recently ran across a couple of old blog posts that make for interesting reading, Is OR/M an anti pattern? by Ayende, and ORM is an anti-pattern by Laurie.  I’m hearing this line of thought more often as more developers use EF and other ORMs in production apps and then have a couple of years of living with the consequences.

So it’s easy to knock something, but what’s the alternative? For me it’s been moving to a simpler data mapper instead of a full on ORM.  I first wrote my own simple data mapper, but since then I’ve discovered Dapper.net by Sam Saffron and Marc Gravel.  On the surface Dapper works almost identically to the mapper I wrote, but under the covers it’s way better and much more efficient. So I’ve been porting all of my old code over to use Dapper. 

The results so far have been fantastic.  Sometimes I have to write more code that I would have to write with a full-on ORM, but I find that I can make major application changes (relatively) quickly and easily and I have never once spent hours struggling with my persistence architecture trying to understand why I’m erroring out on an update for an object graph, or troubleshooting lazy load issues, or select N+1 issues, or thinking to myself “If only this was SQL I would know exactly how to do this”.  Instead it just works, exactly the way I expect it to, and in the end that saves a lot of time and effort.

Great Backbone.js Tutorial

I definitely think that JavaScript is the future (at least the near term future) of app development, and I recently converted HireFlo to a single page JavaScript app.   You know the type, where you only have 1 real HTML page and it defines the main content areas of your site.  Then the rest of the app is all JavaScript that is used to load content into those areas mostly through AJAX and client side templates (check out jsrender). 

After doing the HireFlo rework, and seeing the rats nest of JavaScript that I created, I can definitely see the value of using a JavaScript MVC or MVVM framework to manage my JavaScript UI code.  One framework that I’ve been looking into is Backbone.js.  It’s a full-on MVC framework for JavaScript.  How cool is that?  The more I learn the more I like, and I think I might be refactoring HireFlo in the near future to use Backbone. 

If you want to take a look at Backbone, check out the Backbone.js Wine Cellar Tutorial by Christophe Coenraets.  It’s the best intro I’ve seen so far.

Awesome Startup Architecture List

 

I wanted to put together my short list of awesome stuff you must have if you’re building a new web application on .Net. Each of these libraries is free, open source, and takes the simple, no-nonsense approach to getting things done that is essential in a startup. Before I get into the list just let me say that jQuery isn’t on the list because I just assume that you’re already using it, and because it’s already included by default when you create a new .Net web app.

Dapper
You really can’t make the claim that there is any one right way to do data access... but this is the one right way to do data access.  It was written by two of the guys at StackOverflow and it gives you reflection like functionality without reflection.  They actually emit IL.  It’s cool.
http://code.google.com/p/dapper-dot-net/

Automapper
When you find yourself writing that mapping code between your DTOs (or entities) and your ViewModels, save yourself some time and just use this incredibly useful convention based mapping library by Jimmy Bogard
https://github.com/AutoMapper/AutoMapper

NLog
It’s a good idea to bake logging into your app from the beginning. I have no idea why people still use Log4Net (confusing) when NLog (simple and awesome) is out there.
http://nlog-project.org/

Quartz.Net
Surprisingly powerful scheduler.  Ideal for writing processors, console apps, and windows services that do things on a schedule.
http://quartznet.sourceforge.net/

Twitter Bootstrap
CSS and Javascript that gives you a whole UI framework and a bunch of themed widgets to build a modern webapp on top of.  Before you write any UI code, spend a day experimenting with Bootstrap. It’s amazingly useful and it gives your app a super polished look.
http://twitter.github.com/bootstrap/

JsRender
Javascript templating done right.  Indispensable if you’re  writing a single page javascript app using Bootstrap, BackboneJs, or KnockoutJs.
https://github.com/BorisMoore/jsrender

dotLess
A .Net port of the Less CSS library. In the style of FakeGrimlock: IT MAKE CSS MORE AWESOME!! 
http://www.dotlesscss.org/

jqModal
Simple jQuery based dialog boxes and modal popups.
http://dev.iceburg.net/jquery/jqModal/

The 5 Step Recipe for Building a Startup: Developer Edition

Building a startup is hard.  If you spend any time around newtech meetups or startup groups you’re constantly running into people who all seem to have the same problem, they’re a business person with this great idea, if only they could find a developer to build it.  Seems like if you’re a developer and have a startup idea you’ve got it made, right?  Wrong.

Developers have the skills to make their own vision a reality.  That’s a huge advantage, but it’s also a problem. Because developers are really good at building things with code, the first thing they usually do is…write code.  That’s the absolute wrong place to start, and that’s why most developers wind up producing something that nobody wants, with no users, and no idea where to go from there. 

The key to not being “that developer” is to start with the business side.  Don’t start writing code right away. Instead start thinking through your app, start talking to potential customers, start doing things like collecting emails that measure the interest in your idea.  Now I’ve done this wrong a couple of times, but I like to think that I can be taught, and this post lists the 5 simple steps that I’ve learned for making a successful startup.

1. Mock

Buy a copy of Balsamiq mockups and mock your app. Not just the landing page, all of it. Every screen.  This will force you to focus on the user experience side of your app (which is the only part the user cares about) and work through a lot of the logical problems, application flow problems, stuff like that.  It will also give you something you can show to other people when describing your idea, which leads us to....

2. Talk

Take your mocks and show them to as many people as you can who are potential users.  That part's important.  You want to talk to people who are in your target market.  Talk through the idea, talk through the app.  Listen.  Listen most to the people who love your idea and the people who hate your idea. Those are the people who care. Figure out what the key values that your product provides are from your customer's perspective. Also, as you get feedback, you should be updating the mockups incorporating the things that you'

This is the step that most developers will want to skip.  Don’t.  Talking to potential customers is the most important thing you can do as a Founder.  It’s uncomfortable, it’s tough, you’ll find yourself fumbling for words and talking in circles trying to figure out how to describe your product.  You’ll feel like an idiot for the first 10 or 20 conversations, but then something will start to happen.  Just by sheer force of repetition you’ll find that you’re starting to figure out how to describe your product clearly, and you’ll find that you’re saying a lot fewer words while doing it.  You’ll also develop a picture of what the benefits your product brings that seem to interest people the most.  This is what you’re after.  This whole process is necessary to teach you what your product really is and what your key value propositions are.  It’s not easy but it’s absolutely necessary. If you’re not willing to do it then go work for somebody else, you’re not an entrepreneur.

3.  Announce

Now that you have mocks, and you know what your key value props are (because you talked about it with many potential customers) it's time to put up the "coming soon" page.  I would recommend doing a single page that describes the key value props and includes a screenshot.  The screenshot isn't a real screenshot of your app.  You don’t have an app yet.  You can hire a designer to dummy it up from one of your mocks.  I would recommend spending a few hundred dollars on 99designs.  You can get every thing done at once, a good looking design for your "coming soon" page, a dummy screenshot, and a nice text treatment (no icon needed at this point) for the logo.  Get this page up and start collecting emails of potential users. 

If you're really ambitious and have something to say, you may also want to start a blog at this point.   But don't blog about building a startup, blog about the problem space that your product is for.  Blog about things that show your expertise in that area, and write things that your target customer will want to read because it's relevant to the problem that you solve.  If you're building small business accounting software, then blog about small business accounting issues. Remember, the purpose of the blog is to attract and reach potential users, not other startup founders or the hackernews crowd.

4. Bizspark

If you’re building on the .Net stack you absolutely need to join Bizspark.  Microsoft will give you free licenses to basically every product they make, including SQL Server, and a free MSDN gold subscription, for 3 years.  They figure 3 years is long enough for you to get going so after that they want you to pay for new licenses, but here's the great part, they let you keep the licenses you're already using.  So you don't wind up in a situation where you're just scraping by, then 3 years is up and you have a big Microsoft bill to pay.  It’s great. Microsoft has basically taken the cost factor completely out of the equation for new startups, and it ‘s a perfect program for a .Net developer who’s building their first startup.

It may seem odd that I didn’t start with Bizspark as step 1. There’s a reason.  You’re not ready to join Bizspark until you reach this point.  Keep in mind that Microsoft doesn’t just accept everyone who applies to Bizspark.  You actually are required to have a company, a website, and a sponsor.  Your sponsor can be a company that has some kind of partner relationship with Microsoft, like Rackspace, or it can be a person employed by Microsoft, like Aaron Stannard who is the startup evangelist for Microsoft (aaronst@microsoft.com).  So you’ll need be ready to describe your app and you’ll need to have a website up, not a completed product, just some type of website for your company.  The “coming soon” site is fine for this requirement.

5. Build

Now that all that other stuff is done, now you start building the first version of your app.  Note that you should continue to talk to potential users, you may even want to establish a small group of users who you show your app to as it's being built.  The key point is that step 1 is not finding a developer, step 1 is not start building.  Building the app doesn't happen until step 4. 

While building, do not follow the common advice "don't worry be crappy".  Nothing you produce should ever be crap.  Instead I would recommend taking the 37Signals approach "Build half a product, not a half-assed product".  In other words, your MVP should have half the features you want it to have, but what you do build should be awesome.

To give some technical specifics, I highly recommend building on MVC, not WebForms, and I recommend using a virtual server like an OrcsWeb cloud server or a Rackspace cloud server, not Azure.  The reason is that for an early stage startup speed and flexibility are paramount.  You’re going to be making major changes to your app on a regular basis for the first few years.  MVC is a framework that embraces change and makes those changes faster and easier than Webforms. 

The same principle applies in reverse for Azure. Azure solves the problem of scale, but scale isn’t your problem. My experience, and the experience of a couple of other startups I have first hand experience with, is that Azure slows down development. I think it makes your development slower and less flexible. Debugging is a pain, setting up your environment is a pain, deployment is a pain, the DAL becomes something you actually have to spend time and effort on, plus… what if you decide you need to run Redis or MongoDb or some other open source thing?  Microsoft will probably make it possible so they can check off that box on the feature list and claim that it works, but odds are it will be a whole lot harder than just installing that software on a regular server.  What if you end up needing to have 10 different services running?  Is each of those going to be a separate Azure instance, and thus an additional bill? You don’t want to spend time worrying about stuff like that in the early days when your app can change massively every 2 weeks.

At the beginning, I think you’re much better off just buying a single cloud server.  It runs just like a real windows server, it provides a familiar environment, it’s going to be a solid single platform that you can load up with whatever open source code and services you need (without paying extra), and you can scale it up if you you need to.  Later, when you know what all the pieces of your app are and you have customers pushing the limits of your cloud server, that is the right time to look at Azure.

Should you use .Net for your Startup Company?

I get this question a lot, from both people inside and outside of the .Net community, and it came up again the other day on Quora.  Below is my answer.  Please keep in mind that this is my opinion, and I can’t promise that I’m right, but I can promise that this is what I really think and if you walked up on the street and asked me “should I use .Net for my startup?” this is what I would tell you.

In spite of the fact that I’m a pretty high end .Net guy, I would caution new startups that are considering using .Net.  I think .Net is awesome, and I use it for my own startup HireFlo.  However there's one big landmine that could handicap your startup before it even gets going, webforms.

You see, ASP.Net development is divided into 2 camps, and there are major architectural differences, and cultural differences between them.

 

ASP.Net MVC is awesome for startups

ASP.Net MVC is the awesome new framework that is heavily influenced by Rails and is the platform of choice for startups like StackExchange.  It’s a breath of fresh air for skilled .Net developers who want a framework that embraces the way the web works instead of struggling against it.  This camp is full of people who care about the craftsmanship of writing code and who like to actually ship software.  A programmer in this camp is likely to be familiar with lots of open source projects, and is most likely a great fit for your startup.

WebForms is death for startups

The other camp is WebForms, a festering bog of evil, spaghetti code, and hate. It's the domain of corporate developers who prize process and documentation over shipping code and hope that the glacial pace of WebForms development will hide the fact that they haven't shipped a product in years and can't tell the difference between an HTTP GET and an HTTP POST.  I mean it.  WebForms and it’s poisonous PageLifeCyle pattern are a sink hole of productivity and they are going to resist you every step of the way as your startup struggles to find the right fit between your application and your market (product market fit).  Plus Webforms and the cursed UpdatePanel make it incredibly difficult to do the fancy new style of client side javascript app that tools like Backbone.js, Knockout.js, and jQuery have made possible. 

So the answer is…Heck yes you should (as long as it’s .Net MVC)

So .Net is awesome, C# is amazing, MVC3 is hugely productive,  if you find a .Net developer who works with those, I'd recommend using them.  But you've got to be careful.  A WebForms developer with a corporate dev background is most likely going to be death for your startup.

 

There are three other points I want to add that I think are relevant.

Don’t use Azure for an early stage startup

Microsoft is really pushing Azure as a platform for startups.  I strongly recommend that early stage startups do not use Azure.  Azure development is significantly slower than straight up .Net development that runs on a windows server or VS.  Deployment takes longer, debugging takes longer, the Azure environment is difficult to replicate on your local dev computer, backups are a pain, and you're locked into a single hosting provider.  It all ads up to a lot of inflexibility and friction at a time when your startup needs flexibility and speed over all other things.  Azure can have a place later, when scale is your problem, but at the beginning of your startup that isn't the issue.

The ASP.Net MVC/C#/SqlServer stack scales like a madman

Listen to the middle days of the first StackOverflow podcast and you'll hear that for a long time they ran StackOverflow on a single server.  They were serving a million uniques  with the web app and database running on a single box!  It wasn’t even a very big box.  This is consistent with my experience with .Net.  It scales well. So, if your startup does make it, you'll probably have a much easier time scaling the .Net stack than you would with say Ruby or PHP.

Bizspark is proof that Microsoft loves programmers and startups 

If you want to build a startup on the Microsoft stack, they will give you free licenses to basically every product they make, including SQL Server, and a free MSDN gold subscription, for 3 years.  They figure 3 years is long enough for you to get going so after that they want you to pay for new licenses, but here's the great part, they let you keep the licenses you're already using.  So you don't wind up in a situation where you're just scraping by, then 3 years is up and you have a big Microsoft bill to pay.  They don't do that, they just let you keep using the software. So Microsoft has basically taken the cost factor completely out of the equation for new startups.

HireFlo, an actual startup built on .Net

What have I been doing for 10 months?

I’ve gotten a number of emails asking for part 2 of the ValidationLabel post that I wrote 10 months ago, and a number of people have said there’s problems with the sample code on aapl.codeplex.com/ and asked for updated code samples.  Sorry about that.  There is a reason I’ve dropped off the face of the earth for the last year.

That reason is HireFlo.  I took all of the principles I’ve been discussing here, the techniques for creating an architecture that embraces change and can quickly adapt to massive changes to the application, and I put them into practice with my own startup.  HireFlo is an Applicant Tracking System designed for the small business market.  It takes all the tools that recruiters use like jobsites, aggregators, social networks, resume databases, and wraps them up in a simple app designed for small business users who probably don’t even know that most of those tools exist. 

I’ve been building HireFlo for about 18 months. It’s an ASP.NET MVC app that uses AAPL for persistence, and I have to say the MVC and AAPL combination has been a huge success.  I’m on version 4 of the app and I’ve made some massive changes since version 1.  That’s what happens in startups, and why an architecture that embraces change but can still scale, is so incredibly important.   Each time I’ve made major changes, MVC and AAPL have made the experience as quick and painless as possible.  

The last major change was November 2011 when I decided to completely throw away the old UI, and rewrite a simpler, streamlined version based on a Kanban board, and also make it a single page Javascript app in the style of backbone.js and knockout.js apps.  I completed the complete rewrite of every page, controller, HTML template, CSS file, and Javascript file in the app in just 14 days.  This would never, never, NEVER have been possible if I’d used WebForms or a more Microsofty approach to persistence that used a bunch of sprocs and hard coded mapping logic in my data and business layers.

So anyway HireFlo is up.  It’s been officially launched since August 2011 but I would say the real launch was end of December 2011 when I released version 4 of the app and the redesigned marketing site.  So far there about 300 companies using it.  It’s a start.

What’s coming next

So the first thing I need to do is write Part 2 of my last post.  This part details how to take a helper method and turn it into a strongly typed helper method by using expressions and lambdas because…. well because doing that is awesome.  After that I’ve got a lot of tech problems that I’m solving for HireFlo and I’d like to share them.  I just need to find some time and get back on a somewhat regular schedule.  BTW, I’d also be happy to give updates on HireFlo if you’re interested.  Just let me know.  -rudy