I have a design dilemma with a large ORM or non-ORM, and I will be very grateful for your answer and the reason for my question below, so I tried to include as much background as possible.
Background.
I am developing a completely new web application and decided to use .net (C #) for the service level and business objects and MS SQL as a database.
I planned to create a data-driven model and keep the domain and table objects aligned well enough to avoid too much O / R impedance mismatch. The reason is that I like the OO design (clean, testable code and encapsulating domain logic in particular), but I really don't like the idea of ββdealing with a relational database - in my experience no one wins the OO vs RDBMS game.
The developers of 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 solve the data access / persistence method.
The choice
I narrowed my choice for saving data: ORM, data display unit or handwritten code.
I used nHibernate before and was going to offer it for this project, since it saves all manual plumbing, and we have a completely new database schema that we control, and not some kind of inherited beast.
I am happy to accept the nHibernate dynamic SQL file, and I am ready to give up database management and take advantage of: fast development, 1/2 level caching, lazy loading, good query support, etc., but one problem for me:
Session management - the persistence of a session for an isession request regarding HTTP calls just scares me and always seems a little prone to errors / outdated data. Shifting a possibly complex and dirty graph object in an asp.net session and trying to reconnect it, it seems, is just risky - I remember problems a few years ago with runtime errors on lazy assemblies when reconnecting sessions - I remember how days spent trying to understand what ORM does - the abstraction of data storage was more like abstraction of teeth! I did not understand why I had to study it at such a low level to be able to use it.
My worries about managing an ORM session and that I was trying to avoid a massive mismatch between the DB and the objects made me look at something like MyBatis.net as an alternative (which I assume is used by myspace).
In previous projects, I manually created the BL / DAL code, i.e. displayed properties in table fields - data marshaling between objects and stored procedures. Lazy-loading, select n + 1, caching, etc.
This obviously takes a little time and a lot of boring, repetitive code, but you get a well-known system and you can easily control it: debugging is much easier.
Question
Based on my miss above
1) should I give nHibernate another chance and vow to love him and know him inside out or
2) Should I learn and use something like MyBatis.net and use my knowledge of SQL? or
3) Manually create a display code?
or something else?