I work alone (unfortunately) for a mid-size firm and am involved in aggregating very diverse types of data to eliminate data silos such as accounting packages, miscellaneous access dbs and excel workbooks, and payroll packages. On top of that I am building a package to handle construction material's testing procedures/calculations. Being all alone forces me into being very interested in things that make my life easier. Most tools that I find in development are great, but the overhead associated with learning them in lieu of just building what I need is often not cost-effective. About seven months ago I *finally* gained clarity on architectural decisions I had been fudging and at the same time was introduced to the value of O/R Mappers. I read they saved lots of time for data access and were recommended by Martin Fowler, so they warranted an investigation.
O/R Mappers seems to be a whole world in itself for .NETers; necessitated, i suppose, by the fact that Microsoft hasn't deployed a solution/framework like it on their own. I don't much care about the reasons why this is, and don't have time for DLinq (the artist formerly known as ObjectSpaces???) to materialize. What especially appealed to me was the possible liberation from writing acres of ADO.NET code or using EnterpriseLibrary's data access block (tho it is very cool)...the fact is, I wanted to spend time writing stuff that performs business logic and not have to manually hydrate every object or perform ops on them with the Db. It's important to understand ADO.NET, granted, but as a newbie I suffered from being bogged down by all the monotony of data access.All O/R mappers promise this liberation, of course, and that is the primary reason for their existence.
What struck me at first about the whole OR mapper world first was the diversity of different frameworks/solutions that exist for this. It's great to see the creativity people have employed to do so many tasks. This led me to make my first decision on what I wanted out of a mapper. Unfortunately, alot of times, I found that the creativity of the vendor/project and the breadth of their services were also invasive. Things like requiring me to inherit from base classes/interfaces, attributes flags, etc. were something that seemed a little too much commitment to marry my application to (I'm a guy). In retrospect, after having worked with an O/R mapper I love for a while, it probably isn't as big of a deal as I made it, but it certainly deserves serious thought. I decided against mappers that required this kind of interaction/coding.
My next decision to make was whether an O/R mapper that performs code generation was an alternative. This avenue seemed unattractive to me...I'm sure this is great in some instances but I wanted a cleaner solution and not more code to maintain (generated or not). There are great templates out there and I will eventually be smart and look into CodeSmith (isn't it ironic I am writing a blog while complaining about not having time?).
My next decision was how *much* time I could spend learning a tool like this. Learning curves can be steep on many of these mappers since it is taking over such a significant part of your architecture. I'm willing to invest time if it will save me time eventually, but I wasn't interested in learning some one's language only to find only they speak it!
There isn't a lot of really great organized lists of these mappers, so it takes some creative googling. There were a few reviews/articles I read, but they either were too high-level or outdated (some projects had been abandoned).
One thing that struck me in reading various posts by authors/creators of these mappers was the aggression people seem to exhibit when discussing this topic. At least one contributor to several posts seemed so accusatory and defensive that I decided not to even look into his product for that very fact alone (and the fact that he STILL doesn't support .NET 2.0 new features). I don't care how amazing a product is, I get irritated when I see a vendor correcting people on blogs about semantics or being rude. One fella who was very kind and helpful consistently was Paul Wilson. He has his own OR mapper at www.wilsondotnet.com and because his product supported the new C# feautres in .NET 2.0 I checked his product out first. For only $50, it's well worth it to look at his product. What I found was his product was VERY easy to learn and I think is a great way to start learning about OR mapping, even if you use something else in the end. The documentation is sparse, but he's real helpful if you need something via posts/email. The only reason I eventually abandoned using his product on my project was inheritance. His mapper doesn't support multi-tabled inheritance trees. I appreciate what I learned about how critical this really is, but there were just too many situations I had that I needed to have the normalization that multi-tabled inheritance would ensure. Aggregation is always an option, but I just didn't want to do that all the time.
I had read that his mapper was somewhat similar to NHibernate. At the same time, I learned about NPersist. NPersist does support .NET 2.0. NPersist seems like a great project and the authors seem very helpful, but the following just didn't seem to be as great as NHibernate. The Nhibernate community is very active and NHibernate SUPPORTS three different inheritance strategies. That kind of flexbillity sold me on NHibernate and I have been very pleased with it. It has a steep learnign curve, but has been worth it. It doesn't support .NET 2.0 generic collections, nullables, etc - but there have been contributions to the project that act as temporary solutions. This has made Nhibernate a bit invasive, but nothing I can't tolerate.
All in all, I'd recommend any developer who is working on his own and learning at the same time to examine these O/R Mappers. It has saved me tons of time in the end and along the way I have learned other ways for doing things.