Robert wants to know why everyone is building O/R Mapping tools...

Robert McLaws wants to why so many people are making O/R Mapping tools?

Certainly not for the money because nobody is charging all that much and getting into a business to sell a product that Microsoft is going to be giving away for free in the future would not be financially fruitful lest one could target themselves for acquisition. Seems the only company who might execute on such a strategy successfully is SourceGear (HINT TO MICROSOFT, Eric will not retire if you give him millions of dollars, he will just by a fancy car and take one of those famous “sabbaticals” to get rejuvenated!”)

Age old problem...Writing code is part art, therefore there is no "right" way to do many things. In most real world business apps a very large portion of the code deals with database IO thus this is also the place where there tends to be the most problems.

OOP lends to reuse and the natural progressions of things would dictate the redundant nature of DBIO calls would lend toward a reusable subset specifically tailored to the project needs. Since the refinement of this subset can raise overall quality by abstracting the common problematic code, and increase speed to market (common argument of reuse) this is a high value target for re-factoring.

Back to the art aspect; many people see other peoples code (written or generated) and cringe. They look and say, "too cluttered, I can make it prettier" or "why did they do X, I can do it using Y". Since the O/R mapping concept is relatively easy to understand, many devs embark on the creation of their own mapping tool because in their own mind, they can write "better" code; even though such a distinction is in many cases a subjective one at best.

My belief is that most people build code generators or O/R mapping tools for a specific project and refine it over time, since most OOP devs hate the idea of target specific coding (step-sister of hard coding), they tend to write their code as “generically” as their allotted time will permit them.

I have a tool I wrote that looks at a table and generates code to reflect against that table. Not really a O/R mapping tool and not really a great generator (even though I use the Code DOM and can generate in many different languages J ) but I can see where this type of tool can be the genesis of a mapping tool. I would be interested to hear from the likes of Frans and others who make commercial tools to know how they came to build them.

Dave Wanta of ASP.NET Email fame told me at the KyDotNET users group last month that he heard the ObjectSpaces team had been researching and developing for over 5 years; if this be true I think we can expect some truly innovative things when this hits true fruition.

2 Comments

  • Forget Objectspaces for the innovative things. O/R mapping is not new, in the Java world the concept is used for years. Microsoft-targeting developers however think differently, more in DAL, tiers and stored procedures.



    When I first started with .NET I needed a training project, and I thought a bugtracker would be great. I designed the database in visio's ORM modeller and I found out I had a lot of tables to target. I decided to write a generator first to generate stored procedures and .NET classes. This generator was released in the summer of 2002 as 'LLBLGen', and was a worldwide hit (35,000+ downloads and counting)



    Business was slowing down here (we develope n-tier webapplications) in late 2002 and more and more people asked me to upgrade the initial generator to do more sophisticated things. We decided to take it chance and do it: upgrade the tool to a commericial application. At first it had the design of a tool which built upon the same concept as LLBLGen 1.x: generate stored procs for tables, then define classes to call these procs, and then define classes to define your BL code. I wrote a graphical stored procedure editor but it was so time consuming, it would never be productive (and it had to be database generic). So I dropped that concept, lost 2 months of work and started from scratch again to build a full O/R mapper with a twist: added support for stored proc calling, database views and typed lists (views on entities for fast read-only data retrieval) and it had to be very productive: almost click and go. It took me 9 months to write it but it was worth it. The tool that became LLBLGen Pro is a success and because of its design can and will be extended in the (near) future (it can even target objectspaces in the long run with a new template set if you want, from the designer).



    People say the market is full and a lot of companies fight for a small set of developers but I disagree. There are over 6 million .NET developers out there and even with 1% of them looking at O/R mappers, the market is huge. :)



    I also would like to add: it looks like a lot of people seem to write O/R mappers today, but it is hard to produce a tool that is finished, releasable and usable to others. If you take that into account, the group of people writing these tools is pretty slim.

  • "I also would like to add: it looks like a lot of people seem to write O/R mappers today, but it is hard to produce a tool that is finished, releasable and usable to others."



    If devs are doing this for themselves, it doesn't matter if the stuff is finished, releasable, or usable to others. It works for them, and is still competition to your (or others) product. This fact does not mean they are not writing O/R mappers, so you can't reduce the size of the group of people writing them.

Comments have been disabled for this content.