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

My blog has moved.
You can view this post at the following address:
http://www.osherove.com/blog/2004/9/3/wilsonormapper-at-version-30-and-whats-an-or-mapper-anyway.html
Published Friday, September 03, 2004 9:29 PM by RoyOsherove

Comments

Friday, September 03, 2004 5:58 PM by Scott

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

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? ;)
Friday, September 03, 2004 6:08 PM by Roy Osherove

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

Scott: oops :) I forgot about that bit of trivia. Nope - no information about that....
Friday, September 03, 2004 6:48 PM by Mike Gunderloy

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

I goofed - WilsoORMapper is inexpensive, but not free. Free demo, but $50 to register over at http://www.ormapper.net/ .
Friday, September 03, 2004 7:12 PM by Paul Wilson

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

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.
Friday, September 03, 2004 11:30 PM by Shannon J Hager

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

I had a project that required a ton of DB work that wasn't covered by CRUD interactions a few months ago so I decided to try LLBLGen Pro. I don't think I will go back to hand-coding that sort of code like I was a year ago.

http://hdconsultants.us/archive/2004/05/24/690.aspx

I liken it to the difference between writing an ASP.NET site in notepad and using command line compilers vs. using VS.NET. Well, maybe not THAT much of a difference, but still similar: it's great to know both but I'd prefer to do it the more efficient way.
Monday, September 06, 2004 11:09 AM by szoke

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

I suggest to give a chance for NHibernate, the port of Hibernate 2.0.3, http://www.nhibernate.org , which just entered into alpha stage, which is surprisingly stable.
Saturday, September 11, 2004 6:31 PM by TrackBack

# Items of interest from last 10 days of weblogs.asp.net

Saturday, September 11, 2004 6:32 PM by TrackBack

# Items of interest from last 10 days of weblogs.asp.net

Thursday, September 23, 2004 2:42 PM by Luc

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

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).