WilsonORMapper at version 3.0, and what's an OR mapper anyway?

4 Comments

• I thought Objectspaces was dead and folded into WinFS? I asked over at Channel 9 if ObjectSpaces could be released in the same Indigo/Avalon timeframe but haven't gotten a response yet. Do you have some inside info due to your access to the super-secret MVP newsgroups? ;)
  
  

• Scott: oops :) I forgot about that bit of trivia. Nope - no information about that....
  

• My ORMapper's goal is to be as simple as possible, unlike all the others on the market. In order to achieve that, and since its a part-time project that doesn't pay me as much as I put into it, I've intentionally not tried to cover the more advanced features that aren't needed in the more common 80-90% of basic CRUD cases. COM+ distributed transactions fall into that category in my opinion -- note that I do fully support ADO.NET transactions, which is all you need in the vast majority of cases. If you really do need the more advanced features then definitely look at either Thona-Consulting's EntityBroker or Frans' LLBLGen Pro. They are both very good products, much more full-featured and documented -- but also far more complex in my opinion if all you need is the basic CRUD! My mapper also excels at working with just about any database out there -- again mostly because it handles the basic CRUD that doesn't vary all that much across databases.
  

• Allow me to express my support for NHibernate, as well. Hibernate is an amazingly mature project, and even though it will be some time before .NET coders (like myself, although I'm also a functional languages buff) can access all of the power that Java's Hibernate project brings to the table, and while you may want to hold onto your existing DAL "just in case" (it's what I'm doing), I will say that NHibernate is pretty powerful thus far. And I'm someone who loves SQL and SQL coding; however, the fact that NHibernate can provide the vast majority of my functionality simply based off of a mapping file, with zero lines of code written by me for CRUD, is a huge plus.
  
  
  
  Hibernate3 lets you integrate more seamlessly with databases (stored procs and arbitrary handwritten SQL if you prefer), but honestly I feel that until we get a more expressive language than what is provided by the SQL standard, handwritten SQL code (including much of what is now generated SQL code in ORM mappers) should be for purely data-based, not problem-domain-based, retrieval and editing of data. This would include things like reporting, which are often heavily removed from the problem domain.
  
  
  
  Obviously, if requirements for speed and efficiency are of high enough importance, it becomes more acceptable to invest time in the creation and maintenance of handwritten SQL code.
  
  
  
  (disclaimer: I like Code Generation, I've read and used the techniques used in K. Dollard's book, but I think that in most cases, if the problem is simple enough that code generation techniques make big differences, it's time to consider whether or not that simplicity can be generalized, and whether or not the problem would be best dealt with using more dynamic techniques. YMMV, as there are significant challenges to applying dynamic techniques in most languages built on the CLR.
  
  
  
  So I'm a tiny bit biased against code generation anyways).