Choosing an ORM for a "simple" SaaS startup (ASP.NET MVC)

I'm about to start developing a web-based application that I can best describe as a specialized version of 37Signal's Highrise contact management app, targeted towards service businesses such as lawn care. I've decided to use ASP.NET MVC to take advantage of my BizSpark membership and to leverage the C#/ASP.NET/SQL Server that I already know.

I'm doing a bit of research to choose an ORM for the project; I'm not sure if I should go with something lightweight such as LINQ to SQL or go with the big guns of NHibernate. At this point I don't envision the application as being overly complex. I essentially have these models:

• Account
• User (provided by ASP.NET, but I might need to extend it)
• Customer
• Job

where the following business rules apply:

1. The account is the master record (since it represents a subscriber) and everything else (users, customers, jobs) hang off it
2. A customer can have more than one job
3. There are two types of Customers: A "lead" and a "customer" - the idea is that customers can request a followup from a form that we provide and be automatically added to the account's customer database, and then an employee can follow up and schedule a job, which "converts" the lead
4. A job can be either one-time or set on a recurring schedule (e.g. every two weeks, once a month)

I have a bad habit of trying to overarchitect things. LINQ to SQL seems like it would suit my needs immediately, but I'm concerned about scalability in the开发者_开发知识库 future and whether the upfront costs of using a more feature-rich ORM such as Entity Framework or NHibernate would make up for itself in query effectiveness and optimization. I'm considering using Windows Azure to host the application.

Any thoughts?

Your model seems simple enough to be supported by Linq2Sql, Entity Framework, and NHibernate.

The biggest choice you need to make is do you want to follow a Domain Driven Design approach to software modeling or do you want to work with your objects as database rows. If you want to get fancy when mapping rows to objects NHibernate is the best choice. If your happy with a 1:1 between your business objects and database rows Linq2Sql and Entity Framework just fine.

NHibernate and to an extent Entity Framework support POCO objects that don't inherit from a base class and can be unaware of their persistence requirements. Linq2Sql can, but its hacky and weird.

As far as scaling goes all three of those ORM tools will get you pretty far yet AFAIK NHibernate has more options when it comes to splitting database servers up and handling cross-database IDs and there is even some Sharding support in the works.

NHibernate also supports the most providers, you can go from MSSql to MySql in an hour, with Linq2Sql and EF ( although support is forthcoming you can't )

So TL;DR:

• NHibernate if you want better POCO support, more scaling features, and "there is a mapping for that" row->object mapping features. FluentNHibernate is awesome. You have multiple provider support
• Entity Framework if you want better designer GUI support and are willing to wait for EF4, vs2010 for a fully featured ORM.
• Linq2Sql if simple db access is all you need.

I've used all three and I'm least happy with EF1, EF4 is better but not as good as NHibernate.

I'm using EF4 with VS 2010 for all future "simple CRUD" apps and NHibernate when I need to get fancy.

My experience has been that the "up-front costs" of Entity Framework are about the same as LINQ-to-SQL for simple data models (assuming you have an existing database schema to work with).

A series of tutorials on getting a simple Entity Framework model up and running is available.

I'm not one of those "LINQ-to-SQL is dead!" people, but it does look like Microsoft intends to invest more in Entity Framework down the road. This to me tips the scales slightly in its favor over L2S. The ADO.NET team blog is a good place to keep an eye on for this.

You may want to consider SubSonic. It appears to be aimed directly at your sweet spot.

After that, I would consider NHibernate. NHibernate has minimal downsides and it can effectively "scale down" to your project. With NHibernate, you aren't boxing yourself in to a limited feature set like you would be with the Microsoft ORMs and SubSonic.

Inspired by the engine that runs stackoverflow.com, I have been working on developing a full-blown CRM and business-in-a-box solution over the last few months. I had lot of reservations about using LINQ to SQL as the ORM (discussion on stackoverflow.com and elsewhere pointed out the fact that the Entity framework was the 'in thing'),however, I found LINQ to SQL to be a breeze to work with, even with its known limitations. With LINQ-to-SQL, I could build a fully-functional prototype CRM within weeks. Currently, the CRM is in late stages of beta with few customers and some of them have quite a high volume of usage (1000s of lead and few dozen users). I haven't seen any noticeable, show-stopping issues with the ORM/database so far.

I have written quite a few SQL stored procedures (and used them with LINQ to SQL) where very complex joins were required. Since I come from a SQL/Microsoft Enterprise Library background, I find it easier to write complex stored procedures in SQL and keeping the basic CRUD operations within the LINQ to SQL layer

indyfromoz

I am currently wrapping up an asp.net mvc application. We used the S#arp Architecture. It is a "framework" that enables developers to leverage NHibernate, Fluent, and a myriad of other best practices tools (DI, etc.) Here is a link to the site.

http://wiki.sharparchitecture.net/

Our team absolutely loves this product and recommends anyone to add it to their technical arsenal when deciding on architecture paths.

I'd recommend this:

1. S#arp Architecture. It uses NHibernate but is highly pre-configured so that you can get up and running in literally few minutes - not only with data but also with MVC and other useful things.
2. ActiveRecord implementation - namely, Castle ActiveRecord. Thsi is very easy to use, but still you need to understand NHibernate a bit.
3. Linq to SQL with Repository pattern. You'll benefit from simplicity of L2S while will be prepared to future changes. Just google for "linq to sql repository".

As my ex-boss said, "it doesn't really matter what you choose, it's important to choose something and start working" ;-)