What would you pick for your ASP.NET webapp; nHibernate, Linq, or SubSonic

Question

Something else perhaps? I am already using nHibernate, but I get occasional issues where a lazy initialized proxy object won't actually initialize. I'm thinking of trying something else. The site has user accounts, user posts and photos, and filtering of those to certain location names and title/description matches. Not to mention voting, rating, and marking as a favorite. All of these cause various amounts of db load.

Answer 1

We're using ADO.NET Entity Framework on a fairly active site (10,000 visits per day). It's been solid for us. Lack of lazy-loading is annoying, but it makes you think about going to the database.

Answer 2

LINQ is a great choice. It is used here on Stackoverflow, and on my current project we are using LINQ for our data access.

Answer 3

SubSonic is currently used in all our webform applications with great success. In a matter of minutes your entire database can be generated from scratch ready to use in your application. Rob Conery, SubSonic creator, has some great webcasts up detailing the process to get SubSonic bits setup in a web application as well as some cool demos to get you started. Check out the SubSonic Project.

Answer 4

I've been using LLBLGen Pro for my ORM for about a year, and it has worked out fairly well. Though I haven't used SubSonic, I'm told they are similar. From scratch it can create a data access layer from your database and be ready to use in only a couple minutes. There a slight learning curve, well at least for me, but the help files provide enough information to get you through almost anything you run into. The application can be used as is installed with no problem, but also supports vast customization (maybe too much?).

Answer 5

Hibernate for Java projects but, no doubt, LINQ for .Net. Why add an external dependency when you have LINQ built in?

Answer 6

I would also go with LINQ although I must admit that LINQ to SQL has layering issues. I have read many articles on LINQ to SQL and all of them suggest that it is basically created for RAD applications.

Answer 7

If your inheritence model in the database works with Linq's very limited inheritence support, then I say go for Linq. If you need more complex inheritence scenarios, then I would say that you should stick with NHibernate and work through any pain you are having with it.

Answer 8

If you're having specific troubles with lazy initialized proxies why don't you go without that? Or lazy-load bags only. I think it's worth a try before you rewrite your app with for a framework without lazy loading.

Answer 9

Another option is Castle ActiveRecord. It implements the Active Record design pattern on top of NHibernate, and also takes away most of the pain of configuration (like its "isWeb" setting, for instance) and mapping.

Answer 10

My experience in the Microsoft Ecosystem:

I've used Linq2Sql on a couple of projects and I have run into the 'Layering' problem that azamsharp mentions.

Not that it would help much if you're dead set on sending POCO back to your Logic or UI layer, but an implementation of the Repository pattern helps a little with that nasty layering and separation of concerns issue.

A good basic Repository Impl

For anything that uses complex semantics like voting or statistics (basically any domain object that needs to be displayed or operated on differently than it's represented in the database) the ADO.Net Entity Framework gives you some advantages. It can simplify your business logic / data access layer by subsuming complicated data retrieval.

ADO.Net Entity Framework Overview

Hope that helps!

Answer 11

I would use NHibernate. The Persistence Ignorance is one of the main selling ponts for me, and not being bound to the database is another. Entity Framework is deeply deeply flawed, more than just the lack of lazy loading. EF and LINQ2SQL are both new technolgoies, whereas NHibernate is very mature and has seen far more action.

Another good thing about NHibernate is the ability to switch databases without editing your. I use this for integration tests that are ran locally, running them against SQLite and then SQL Server on the CI server.

Answer 12

I love SubSonic as it is quite easy to configure and generate a DAL. The implementation is not a full fledged ORM, as it only create a class per table. Being able to use stored procedures compensates for when you need to compose objects that are the results of joins. Again, SubSonic is intended to be functional, so it will help you achieve project goals quickly.

That said, you are not able to use SubSonic to "compose objects" - there is no configuration file that describes the relationships between classes. The database still dictates how you shape your solution.

Answer 13

I don't really care for SubSonic. To me it seems like a very thin DAL tool. With SubSonic, I'm still typing a lot of string literals which seems to sort of defeat the point for me. Personally, I prefer LLBLGen:

http://www.llblgen.com/defaultgeneric.aspx

Frans Bouma, the creator, has a very good blog that discusses many issues around DAL and ORM technologies.

http://weblogs.asp.net/FBouma/