Question

I'm having a big to-ORM or not-to-ORM design dilemma and would really appreciate your answer and reason to my question below hence I have tried to include as much background as relevant.

The Background.

I'm designing a brand new web application and have chosen to use .net (c#) for the service layer and business objects and MS SQL as the database.

I was planning to build a data-driven model and keep the domain objects and tables reasonably well aligned to avoid too much of an O/R impedance mismatch. The reason for this is that I like OO design (clean,testable code and encapsulation of domain logic in particular) but I really don't like the idea of fighting against a relational database - in my experience nobody wins in the OO vs RDBMS game.

The developers on this new project will have both .net and SQL experience - there is no actual DBA figure although some of us have a good level of knowledge.

So now to decide the data access / persistence method.

The choices

I've narrowed down my choices for data persistence: an ORM, a data mapper or hand-written code.

  • nHibernate

I have used nHibernate before and was about to suggest it for this project as it saves all the manual plumbing and we do have a brand-new database schema which we control, not some legacy beast.

I'm happy to accept nHibernate's dynamic SQL and I'm prepared to relinquish control of the database and to enjoy the benefits: quick development, level 1/2 caching, lazy-loading, good query support etc but one thing troubles me:

Session management - the session-per-request persistance of the isession over http calls just scares me and always seems a bit prone to error / stale data. Shoving a possibly complex and dirty object-graph in an asp.net session and trying to reconnect it later just seems risky - I remember problems a few years ago with run time errors on lazy-loaded collections when reattaching sessions - i remember spending days trying to understand what the ORM was doing - the abstraction of data persistence felt more like an abstraction of teeth! I didn't see why I had to learn it to such a low level to be able to use it.

  • MyBatis.Net

My worries about ORM session management and the fact I try to avoid a massive mismatch between DB and objects has made me look at something like MyBatis.net as an alternative (which I believe is used by myspace).

  • Hand Rolled

On previous projects I hand-built the BL/DAL code - i.e. mapping properties to table fields - marshaling of data between objects and stored procedures. Lazy-loading, select n+1 handling, caching etc.

This obviously takes a bit of time and a lot of boring, repetitive code but you end up with a system you know well and can easily control: debugging is a lot easier.

The Question

Based on my ramblings above,

1) should I give nHibernate another chance and vow to love it and learn it inside-out or

2) should I learn and use something like MyBatis.net and utilise my SQL knowledge? or

3) Manually create my mapping code?

or something else?

Was it helpful?

Solution

  1. Yes
  2. Maybe
  3. No

Your primary concern with NHibernate seems to be the session-per-request pattern but I think you have a misconception as to what that is. Session-per-request is a single ISession per HTTP request. It has nothing to do with the ASP.NET Session state.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top