Whats the pros and cons of using Castle Active Record vs Straight NHibernate?

Question

Assuming that writing nhibernate mapping files is not a big issue....or polluting your domain objects with attributes is not a big issue either....

what are the pros and cons?

is there any fundamental technical issues? What tends to influence peoples choice?

not quite sure what all the tradeoffs are.

Answer 1

When I started using NHibernate, I didn't learn about Castle ActiveRecord until I had written my Mapping files and made my classes. At that point, I couldn't visibly discern what Castle Activerecord would give me, so I didn't use it.

The second time I used NHibernate, I simply used myGeneration to make the mapping files and the classes just by having it look at my database. That saved a lot of time by itself, and allowed me to (once again) not worry about Castle Active Record.

In reality, most of your time is going to be spent making the custom queries, and Castle Active Record won't necessarily help with that -- if you were to use myGeneration with NHibernate, you'd bypass most of the work you'd need to do anyway.

Edit: I don't want to seem like a cheerleader for either myGeneration or NHibernate. I just use the tool that allows me to get my work done quickly and easily. The less time I have to spend writing Data Access code, the better. It doesn't mean I can't do it -- but there's little sense in re-inventing the wheel each time you write a new application. Write SQL queries and Stored Procedures where needed, and no where else. If you're doing CRUD operations, an ORM is the way to go.

Edit #2: Castle Active Record may bring more to the table than I realize -- I don't know much other than what's on their website, but if it does bring more to the table, then it would help potential adopters to be able to readily see that on their site.

Answer 2

I found ActiveRecord to be a good piece of kit, and very suitable for the small/medium projects I've used it for. Like Rails, it makes many important decisions for you, which has the effect of keeping you focused you on the meat of the problem.

In my opinion pro's and cons are:

Pros

• Lets you focus on problem in hand, because many decisions are made for you.
• Includes mature, very usable infrastructure classes (Repository, Validations etc)
• Writing AR attributes are faster than writing XML or NHibernate.Mapping.Attributes IMHO.
• Good documentation and community support
• It's fairly easy to use other NHibernate features with it.
• A safe start. You have a get-out clause. You can slowly back into a bespoke NHibernate solution if you hit walls with AR.
• Great for domain-first development (generating the db).
• You might also want to look up the benefits and drawbacks of the ActiveRecord pattern

Cons

• You can't pretend NHibernate isn't there - you still need to learn it.
• Might not be so productive if you already have a legacy database to work with.
• Not transparent persistence.
• In-built mappings are comprehensive, but for some projects you might need to revert to NHibernate mappings in places. I haven't had this problem, but just a thought.

In general, I really like ActiveRecord and it's always been a time saver, mainly because I seem to happily accept the decisions and tools baked into the library, and subsequently spend more time focusing on the problem in hand.

I'd give it a try on a few projects and see what you think.

Answer 3

The biggest pro of AR is that it gives you a ready-made repository and takes care of session management for you. Either of ActiveRecordBase<T> and ActiveRecordMediator<T> are a gift that you would have ended up assembling yourself under NHibernate. Avoiding the XML mapping is another plus. The AR mapping attributes are simple to use, yet flexible enough to map even fairly 'legacy' databases.

The biggest con of AR is that it actively encourages you to think incorrectly about NHibernate. That is, because the default session management is session-per-call, you get used to the idea that persisted objects are disconnected and have to be Save()d when changes happen. This is not how NHibernate is supposed to work - normally you'd have session-per-unit-of-work or request or thread, and objects would remain connected for the lifecycle of the session, so changes get persisted automatically. If you start off using AR and then figure out you need to switch to session-per-request to make lazy loading work - which is not well explained in the docs - you'll get a nasty surprise when an object you weren't expecting to get saved does when the session flushes.

Bear in mind that the Castle team wrote AR as a complementary product for Castle Monorail, which is a Rails-like framework for .NET. It was designed with this sort of use in mind. It doesn't adapt well to a more layered, decoupled design.

Use it for what it is, but don't think about it as a shortcut to NHibernate. If you want to use NH but avoid mapping files, use NHibernate Attributes or better, Fluent NHibernate.