What do you look for in O/R Mappers for .NET?

19 Comments

• Personally, I am not a fan of ORM. The two issues that I run into are a lack of flexibility for implementing business logic and a lack of speed.
  

• Ok, here is what I am NOT looking for:
  
  
  
  * POCO - I have nothing against intrusive O/R mappers, as an O/R mapper is intrusive per definition unless you hide it under another layer. Query code all over the place.
  
  * Extneral XML mapper file. Lots of people love to have the mapping file external to the DLL. This never has been an issue for me, and propably never will.
  
  
  
  I look for:
  
  
  
  * Strong database management. Schema sync, backup and restore mechanisms for data so that the user can easily move from SqlServer to Oracle.
  
  * Full core features.
  
  * Strong support for remoted data access layer scenarios. We had some projects last year requiring this - like client/server over a 56k connection.
  
  * Same for caching. Please give me a disc based cache, so that large objects just send keysd and versions. Again, this may be specific to the projects e did, but when you have relatively static data (images) ofver a 33.6 to 56k connection, you WANT a disc based cache. Note that this can be perfectly valid all the time - you can have a counter in the object that is also transmitted to find out whether the cache is stale.
  
  * Support for DataBinding. Absolute core.
  
  * Location agnostic API. I do not want to have to change a single line of code, whether I work against a local data access layer, a data access layer on a separate computer and/or remote objects.
  
  * Extensible object models. My object models ive, on a project, in maybe 10 different assemblies. I need the ability to have ONE O/Rmapper model spawn them all. Drop in a new model, the same O/R mapper instance knows how to use it. This should include functoinality like substituting object types (accounting works with "Invoice", I replace this type in the factory with a subclass that is MyInvoice and has additional fields).
  
  
  
  And naturally all features that distinguish an O/R mapper from a toy. Which means proper OO support including inheritance, support for all 4 inheritance models.
  
  
  
  I seriously find the dynamic extensibility of most O/R mappers being very poor. Especially code generator ones do not relaly deal, normally, with models that span multiple assemblies. Once you hit 200+ business objects, though, it makes sense to split them into sub-systems (actually it makes sense much earlier, but then you start feeling the pain). Substitution, as mentioned above, is also great for estensible applications. I can use a generic accounting package and use my own extended types in it.
  

• *I look for POCO. I don't want something getting in the way of DDD.
  
  * I look for external configuration, XML or otherwise
  
  * Strong OOP support
  
  * Flexibility in the Object to Table relationship
  
  
  
  I went with NHibernate.
  

• * Not Intrusive (POCO and Xml Mappings)
  
  * Ease of Use (and Easy to Modify too)
  
  * Flexibility (DAL Features, Stored Procs)
  
  * Performance (No Reflection or DataSets)
  
  * Support (Community and Popularity too)
  
  
  
  I went with Paul Wilson's WilsonORMapper.
  

• Simplicity. 100% of the projects I've worked on so far have not required 50% of the features of NHibernate, or other large ORMs. I want to be able to create a nice, object-oriented domain model without having to worry about the details of it's persistence.
  
  
  
  - CRUD an object
  
  - Find an object based on certain criteria
  
  - Handle one-to-many, and many-to-many relationships
  
  - Flexibility. Let me make ad-hoc queries with concatenated string SQL if I really want to.
  
  
  
  That's about it. I basically want an ORM at the opposite end of the spectrum from what Thona talks about. In short, I want a toy. KISS. YAGNI.
  

• Oh, I should have also mentioned that being open source is of importance to me.
  
  
  
  I haven't found one yet that feels right.
  

• I have to agree with Jeff, and the KISS philosophy. Its a given that o/r mappers are another layer on top of accessing the datastore.
  
  
  
  I too find myself wishing for features that I dont need, but "would be cool to have" and I think that's where some o/r mappers go wrong, and begin to introduce complexity into whats usually already complex enough.
  
  
  
  nhibernate is cool, but suffers a little from feature bloat. LLBLGen, i havent had a chance to look at.
  
  
  
  Personally, I've adopted Wilson's ORMapper, since its seems mature now. I have even worked somewhat on updating the code generation for the ORHelper side project.
  
  
  
  Its just so pleasent to write code:
  
  
  
  Quote = quotedb.ObjectSpaceManager.GetObject(typeof(quotedb.Quote), quoteId=1);
  
  quote.DateClosed = DateTime.Now.Date;
  
  quotedb.ObjectSpaceManager.PersistChanges(quote);
  
  
  
  instead of the litany of SQL ;-) +the strong typing +when db fields change, the gen'd code can change, showing me the impact of a schema change...
  
  
  
  I believe we're coming close (maybe we're already there) to an era of software developement that focuses more on solving the business problems, instead of solving the technical problems.
  

• 
  
  I use Paul Wilson's mapper, and love it. Personally, POCO is muy importante, because although Thona may feel otherwise, I don't feel that an "O/R mapper is intrusive per definition." I think Paul's mapper is 90% there as far as what I want. I have used it in numerous projects over the last 7 months and love it to death.
  

• We went with CodeSmith. I know, I know it isnt an O/R Mapper. Frans and Thona have taken every opportunity to remind me everytime I mention it.
  
  
  
  What I like about CodeSmith is the fact that I can be 100% involved in the design of my architecture. It allows me to develop a solid core understanding of the issues with our data and how to solve them. We developed a mapping architecture based on specific rules and standards for creating a database. We do have a mapping layer implemented via class library that handles all of our common functionality. The cool thing we have done with CodeSmith is enforce our standards and design policies instead of just advocating them.
  
  
  
  I haven't tried using any of the O/R Mappers that are out there today, but Paul Wilson's has intrigued me from time to time.
  
  
  
  

• I would like to add that there is absolutely no reason for me to buy a product like Thona sells, because we don't need 1/3 of the stuff he is talking about.
  
  
  
  We use a datamodel driven design. We can generate all of the code we need to interface with a database and consume these entity objects directly via presentation layers or through an added business layer.
  
  
  
  We can plug these assemblies that are generated into any application and plug it into any of our applications.
  
  
  
  

• I went with NEO - lightweight and easy to use, and free
  

• ORM for .NET should:
  
  * Support all the basic operations commonly needed (CRUD, loading lists of objects contained etc.)
  
  * Be easy to use and not impose a complex, crazy set of conventions on me
  
  
  
  and most of all
  
  
  
  * support stored procedures for all CRUD operations!!!!
  
  (hardly anyone does that - why not??? doesn't make sense.....)
  
  

• 
  
  * Good designer for generating schema and entity classes
  
  * Ease of use (simple as possible)
  
  * Strong support of object relationships (graphs)
  
  * Databinding is nice
  
  * Strong OOP support
  
  
  
  And,
  
  
  
  * Price is cheap??? :D
  
  
  
  NHibernate, though still in its Beta, is nice but the lacks designer support for generating schema and entity classes.
  
  
  
  

• "* Not Intrusive (POCO and Xml Mappings)
  
  * Ease of Use (and Easy to Modify too)
  
  * Flexibility (DAL Features, Stored Procs)
  
  * Performance (No Reflection or DataSets)
  
  * Support (Community and Popularity too)
  
  
  
  I went with Paul Wilson's WilsonORMapper. "
  
  
  
  Mega-Dittos!
  
  
  
  The non-intrusive quality is essential if you want to be able to create a facade layer on top of your DAL.
  

• When I was looking for an OR Mapper (did not find one I liked), features that were important to me were:
  
  * non-intrusive, which means an external configuration file and/or code-generation
  
  * exposed object relationships - I wanted to be able to generate help docs based on the OR Mapping, as well as generate code, and expose the relationships to the users for reporting/querying purposes
  
  * lookup relationships - recognition that a "lookup" is a relationship too, but a special type. I want native support for the concept of lookup tables, especially those involving code/literals.
  
  * Good object-query language - need a nice way to do adhoc queries
  
  * Multiple OR configurations, with interactions - I want to be able to have plugin programs that have their own OR mapping files, but still allow interaction with one or more core mapping files.
  
  * Lazy loading support. Also, optimized lazy loading, which means dynamic recognition and optimization of lazy loads that are parallel/related. (don't query for 1 record 100 times when you can query for 100 records 1 time).
  
  * Automatic relationship management (I do not want to manually set foreign key values)
  

• Everyone I've convinced to use LLBLGen loves it and wouldn't use anything else.
  

• I started with CSLA.NET and soon it was obvouse that maintaing 5+ stored procedures for every table in a 200+ table database is a nightmare especially when part of your logic is in the SP.
  
  I wanted something to allow to generate my DAL in less than 5minutes and support any DB I want. I wanted something that allowed me to build my own templates and integrate my BL class where I see fit.
  
  I didn't want an OR mapper to enfore or constraint my work....
  
  I didn't want an OR mapper that created crazy table structures in my database
  
  one OR mapper fit the bill... LLBLGenPRO
  
  
  
  I started using LLBLGenPRO more than a year back and its been smooth sailing. We have build a big ERP project, a mall POS system and even a stock market tracking system and all the development time was concentrated on building the DB and wrting the BL logic. No data-access stuff!!
  

• The thing is i see a lot of OR mappers in small projects and they add little value above using datasets.
  
  
  
  Where they come into their own is large nTier systems .
  
  
  
  Hence i want ( most copied from above)
  
  * Not Intrusive (POCO and Xml Mappings)
  
  * Simple and Ease of Use . Most programers cant afford the time to understand an OR mapper and struggle with the learning curve. Hard enough to wean them of Datasets.
  
  * Flexibility (DAL Features, Stored Procs)
  
  * Performance (No Reflection or DataSets)
  
  * Transaction , batch update and bulk insert support.
  
  * Generics support.
  
  * Support (Community and Popularity too)
  
  * Work well with NTier arhitectures and Caching . ie if using output or busines logic caching then little caching should be done by the OR mapper . If a Business component stores all products in memory , then data access is pointless except for persistance .
  
  * Most important an OR Mapper should be little more than a DAL layer. And it should do this very well.
  
  
  
  I also went with Paul Wilson's WilsonORMapper.
  

• 
  
  * Simplicity and "convention over configuration" e.g Rails' ActiveRecord. Custom attributes instead of XML. Infer as much as possible
  
  * Non intrusive (no base class)
  
  * Don't care about Stored Procs
  
  * Stable, good unit test coverage and reasonable docs/examples
  
  * Small clean API
  
  * Lazy loading using runtime IL weaving
  
  * Outer-Join fetching
  
  * Database agnostic
  
  * Lifecycle callbacks
  
  * Optimistic locking
  
  * Logging