Images in this post missing? We recently lost them in a site migration. We're working to restore these as you read this. Should you need an image in an emergency, please contact us at
A Gem of a Lesson from Rails

For the past few months, I've gotten the privilege to develop a good sized, production Ruby on Rails application.  I say privilege because it has shed light on many lessons for the way we develop in the Microsoft community.  The beauty of RoR is that you don't have to spend months or years reading books and blogs on how to put together a properly architected application.  This doesn't mean you're not going to shoot yourself in the foot, but it certainly reduced the risk!  Additionally, if you get a new job at a different Rails shop, you typically don't have to spend a couple months trying to figure out somebody else's homegrown architecture (if you're lucky enough to find any structure at all).  RoR is like a design pattern at the macro-level...pulling together the (albeit opinionated) best practices of data access, layering, and unit testing into a consolidated package.  Obviously, there is never a one size fits all - there are simply too many varying needs to have a single application design fit every scenario.  But it certainly fulfills the 80/20 rule...what RoR has proven is that it's highly effective, on many levels, to have a "preferred path" and common platform for the 80% of web-based application scenarios which it covers nicely.  The overwhelming benefit of having this common platform - with many technical decisions made for you, such as how to validate forms and models, how to setup CRUD communications, how to communicate with the DB, and how to organize applications - is that the community is able to converge on a consolidated preferred practice.

When the GoF wrote Design Patterns, it gave the development community a formalized language to discuss common coding scenarios and recommended practices for addressing those situations. Martin Fowler did the same by formalizing "smells" and refactorings in Refactoring.  This formalization and common language has made it easier for developers to discuss solutions to a problem and to get new developers ramped up to a framework which leverages some of these formalized ideas...assuming they're used appropriately.  Likewise, Rails provides a formalized track for Ruby developers to develop data backed, web-based applications.  This has paid dividends in the availability of guidance, the facilitation of plugins/extension, the enabling of widely used scaffolding generators, and the removal of hours/days/weeks of research and trial & error to find out how the heck do we competently write a dynamic web application with Ruby.

ASP.NET MVC is shaping up to be a spectacular framework.  Frankly, it is far more than a magnitude improvement over traditional ASP.NET.  But the remaining opportunity, if you will, is that it is too specific in nature to provide an end-all "preferred" path for .NET web application development.  What should we unit test with?  How should we talk to the DB?  Who should handle dependency injection?  Should the model really be in the same assembly as the web project?  ASP.NET MVC is similar to NHibernate wherein it's absolutely spectacular in providing a solution for accomplishing a specific task - NHibernate for providing DB communications in a domain driven design and ASP.NET MVC for bringing the MVC pattern to .NET web development.  That doesn't lessen its benefit; it simply doesn't do much to keep a developer from leveraging it inappropriately, knowing which tools should be used with it , and how to properly write a real world application.

One of the primary challenges is that there are simply soooo many options to choose from beyond just deciding to go with ASP.NET MVC.  It's absolutely bewildering at times to know which assortment of tools and techniques are the best to select.  (Try to recall when you first started writing .NET apps!)  To further frustrate the problem, there is no "best" combination of tools and practices.  But just as RoR doesn't necessarily represent the quantifiably best practices/tools for developing web-based Ruby applications, it has given enormous benefit to the Ruby community by providing a formalized, preferred approach.  What's needed then, IMO, for Microsoft web development is an equivalent foundation which leverages ASP.NET MVC with a number of carefully selected tools to provide a best practice preferred path which will cover most web application scenarios.  To begin the plug, that's what I hope S#arp Architecture to be.  I don't intend for it to be merely an example of using ASP.NET MVC...I intend for it to be the Ruby on Rails for ASP.NET MVC which can enjoy benefit from scaffolding generators, standard practices, standard means for creating and sharing plug-ins, a common ground for sharing agreed upon best practices, etc.  Although it won't be applicable in all cases, I feel it's on its way to comfortably covering the 80% of domain driven, web-based applications.

The challenges to aspiring to such a goal for #Arch, and any foundational architecture for that matter, include:

  • Keeping the solution simple enough to be easily learned and to develop with,
  • Keeping it flexible enough to use a variety of options for the presentation layer and other facets, such as the mechanism of dependency injection if desired,
  • Providing tools, such as scaffolding generators and project templates to realize one of the major benefits that such a consolidated framework can provide,
  • Making it dead simple for developers of all skill levels to get an application up and running quickly without being overly constrained by design and without leading to maintenance nightmares down the road, and
  • Keeping it lean enough to avoid the choice-overload that framework bloat often leads to.

I suppose you could say that the above is my commitment to the users of the architecture.  In short, I'm attempting to provide just enough judicious planning for solving common problems without compromising flexibility.  To help you decide if S#arp Architecture is appropriate for your project, you'll want to consider the following assumptions, which aren't necessarily objective best practices, but which S#arp Architecture has built in:

  • Domain driven design is the preferred way to encapsulate your model and business logic (e.g., this is great for those of you who get the willies after looking at ADO.NET Entity Framework);
  • Tiers should be loosely coupled and employ separated interface (aka, dependency inversion) to separate service dependencies from domain logic;
  • The ability to unit test all code, from the controller action down to the lowly DB filtering, should be available while supporting a domain driven design (i.e., you shouldn't need to create your database to test all of your business logic);
  • Database access and communications should require little attention and should be minimally intrusive, but without limiting those capabilities; and
  • Preferred practices for a few key areas should be suggested, such as model validation, CRUD mechanics, and application layering.

But even if you agree with these points, this doesn't mean that it'll be appropriate in every situation or that it won't be "too much" in very simple scenarios.  Indeed, the decision of using any base architecture is akin to employing a design pattern (but bigger) should only be leveraged when appropriate and only when it carries its weight.  At the beginning of any project, a number of architectural approach should be compared side-by-side to assist in picking the right tool for the job; a few options to consider besides S#arp Architecture include a homegrown solution, ADO.NET Entity Framework, Castle MonoRail, CSLA, or the full suite of Spring.NET tools.

A commenter on also brought up great points with respect to concerns of future bloat and unnecessary complexity as frameworks evolve and grow, as the life cycle of some architectures have fallen victim to.  These are enormous risks for any framework that attempts to cover the development needs of 80% of web-based applications; there are a few more tasks which need to be done to bring #Arch to version 1.0 and almost all of them are focused on further reducing complexity without limiting flexibility.  Certainly one of the success factors of Ruby on Rails is that it hasn't tried to continue to add tons of new functionality with each new release; it has simply attempted to solve one area - model driven web development with Ruby - in a very clean and competent manner...and then left its approach alone.  I hope S#arp Architecture emulates some of these lessons learned by providing a simple to use platform for developing domain driven, web applications with ASP.NET MVC.  And once it gets to that point with 1.0, I promise we'll leave it alone. ;)

Billy McCafferty

Posted 11-11-2008 4:02 PM by Billy McCafferty
Filed under:



MIke wrote re: A Gem of a Lesson from Rails
on 11-12-2008 2:04 AM

Have you looked at Merb yet? If I were porting a architecture, I'd seriously consider what they are doing over there...much slicker than RoR.

ASP.NET MVC Archived Blog Posts, Page 1 wrote ASP.NET MVC Archived Blog Posts, Page 1
on 11-12-2008 8:57 AM

Pingback from  ASP.NET MVC Archived Blog Posts, Page 1

Billy McCafferty wrote re: A Gem of a Lesson from Rails
on 11-12-2008 9:00 AM

Haven't seen that one before.  The setup that I like the most if the scaffolding generated from ext_scaffold (  This sets up CRUD which can be invoked to optionally return JSON strings; but without cluttering the controller logic with more than a single line of extra code (ok, 2).  I've seen a couple of options for ASP.NET MVC, but nothing I've latched onto yet.

pete w wrote re: A Gem of a Lesson from Rails
on 11-12-2008 9:01 AM

These are good observations.

On my side of the map, our clients demansd quite a bit of .NET development.

My crew prefers to use RoR because its been proven to keep development costs comparatively lower than ASP.NET, and the dynamic types are easier to work with.

One major advantage .NET offers in terms of web apps is a simpler deployment model with IIS compared to configuring a mongrel cluster on apache.

As a compromise between the developers and the client demand, we found a sweet spot using ActiveRecord / Windsor / MVC.NET, but we are still looking for a good "general-purpose" project template here.

I take back my words detracting monorail, after all, is looking more like it with every release (for good reasons!)

I'll take another look at the sharparchitecture. I second the comment above, Merb is another powerful option for most needs.

Billy McCafferty wrote re: A Gem of a Lesson from Rails
on 11-12-2008 9:07 AM

Hi Pete, nice to hear from you - I lost your email BTW...drop an email sometime!

Anyways, we've spent many an hour wrestling Ubuntu/Apache/Mongrel I completely agree with that point.

The one major advantage that Ruby provides over .NET is its language seems that I can do things in far fewer lines of code than I can in C# and the way it reads it quite pleasing to the eye.

Anyway, the Castle suite is a great combo for emulating RoR on .NET...definitely good stuff.  I have a suspicion that ASP.NET MVC was developed in response to RoR and MonoRail...but Scott Gu would have to confirm that one. ;)

Interesting posts of the week at { null != Steve } wrote Interesting posts of the week at { null != Steve }
on 11-12-2008 9:35 AM

Pingback from  Interesting posts of the week at { null != Steve }

Arjan`s World » LINKBLOG for November 12, 2008 wrote Arjan`s World » LINKBLOG for November 12, 2008
on 11-12-2008 9:49 AM

Pingback from  Arjan`s World    » LINKBLOG for November 12, 2008

Rafael Rosa Fu wrote re: A Gem of a Lesson from Rails
on 11-14-2008 9:10 AM

Hi. I'm planning to start studing #Arch this weekend, but after reading this post I'll try to start today :) I'm a big RoR fan, used it a bit myself, and I'm thrilled to find a project that clearly states that is going to import it's qualities and philosohie. I'll try to contribute to it.

A note on deployment "problems" with Ruby. Maybe Fusion Passenger can help out, it's a big hit on RoR community and even the All-mighty DHH recomends it, take a look at the links if can:

But you guys might already know that :)

Keep up the good work.

Billy McCafferty wrote re: A Gem of a Lesson from Rails
on 11-14-2008 10:52 AM

The biggest area of attention that #Arch needs now is a focus on what can be done to get it to a saffold-ready state by considering how coding by convention can be leveraged as successfully as it is in RoR.

eeallo wrote re: A Gem of a Lesson from Rails
on 11-17-2008 3:18 AM

Great article, but could you increase the line height a bit? The text is now quite hard to read.

Just a suggestion.

wayde wrote re: A Gem of a Lesson from Rails
on 11-17-2008 4:28 AM

Hey Billy,

I think the MS community not only wants a comprehensive framework like Rails ... it needs it.  You've made a number of wonderful improvements to the framework to simplify the architecture but I'd like to offer a few recommendations and seconds to some of the things you mentioned in this post.

1.  Eliminate the controllers project and roll the code back into the MVC project.  Separation of concerns doesn't require separation via projects and I think this trivial move would work to simplify the framework and thus, make it more attractive.

2.  Generators.  I'd like to see something akin to what we see in Rails that can also be modified via templates.  If this can be accomplished, a lot of code can be stubbed out in a non-opinionated way (or at least in a opinionated way that can be modified).  Rob Conery has been moving along this direction with Subsonic and I think it's worth checking out.  

3.  Migrations.  Again, check out Subsonsic for a .NET copy of this Rails feature.

- Wayde

btw, for your Rails guys out there ... Phusion Passenger is the way to deploy your RoR apps.  No question about it.  I only wish something like this existed for deploying Rails apps on Windows.

wayde wrote re: A Gem of a Lesson from Rails
on 11-17-2008 2:52 PM

One thing I forgot.

I project/solution template would be helpful that would create the solution, the 4 projects, set needed references/dependencies and include all the other required files along with some default settings is needed as well.  One nice thing with Rails is that you do a rails myapp and the framework is good to go.  Having a project template you can click on in VS would accomplish the same thing.

Mark wrote re: A Gem of a Lesson from Rails
on 01-13-2009 7:13 PM

I'm an old VB6 programmer trying to transition to web programming. I am dying to get past all the decisions on tools and techniques and get back to actually writing code that solves problems. I've been trying to follow MVC and #Arch but am getting lost in the constant changes from one version to the next. Today's frustration:  how do I disable lazy loading now with the sudden appearance of Fluent NHibernate in #Arch? I can't find any cohesive documentation on Fluent NHibernate. After reading 10 or 15 blog posts, I finally found some obscure forum note that that the .NotLazyLoad() solution requires build 136 of Fluent NHibernate. The DLL included with #Arch is version Huh? How do those numbers relate? Fluent doesn't seem to have any DLLs available--so I have to compile my own?

I do appreciate the compilation of tools that #Arch represents. I'm sure I've gotten a lot further in MVC than I would have without it.  But this article has me thinking:  am I still 6-12 months too early? If I need an established, stable framework, preferably with a selection of well-written books available on Amazon, should I be looking at RoR and/or Castle?

Billy McCafferty wrote re: A Gem of a Lesson from Rails
on 01-13-2009 7:22 PM


If you can hold tight for just a couple more days, I'll be releasing S#arp Architecture 1.0 Beta later this week with completely updated documentation.

Social bookmarks wrote re: A Gem of a Lesson from Rails
on 03-24-2013 10:05 PM

eVUkxE I value the article. Really Great.

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Google Reader or Homepage Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of
Red-Gate Tools For SQL and .NET


SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
NHibernate Profiler
Balsamiq Mockups
JetBrains - ReSharper
Web Sequence Diagrams
Ducksboard<-- NEW Friend!


Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers


Community Server (Commercial Edition)