Thought experiment: Objectspaces will limit interest in O/R mapping

Today I've posted this as a reply in the Microsoft.public.objectspaces newsgroup. I think it's also blogging material, so that's why I post it here too. You can decide to react here, on your own blog, but also in the microsoft.public.objectspaces newsgroup, available on the msnews.microsoft.com USENET server.

The person who wrote the quote has a valid point. This is the basis for the thought experiment: will Objectspaces and its quality (and limits) limit interest in O/R mapping?

My problem w/ #4 is that there's no sense creating a vendor dependency on a product that wont be around long after ObjectSpaces is released. Let's face it, without a standards-based approach like JDO to back them up non M$ vendors have zilch going for them other than the fact that ObjectSpaces isn't out yet.

If this is true, MS is thus killing businesses by providing an inferior technology (it supports just 1 db) and still can get away with it. An EJB-CMP or JDO equivalent would have been the best choice, so all O/R mapper vendors could target that spec. Now it's indeed an open market which will be dominated by the one who can set the de-facto standard. It's easy to guess which company that will be.

Still, I think that with the limited feature-set of ObjectSpaces (and the fact that it is not yet available), it is not a good thing for O/R mapping for .NET in general: because it will be seen as the de-facto standard and because its limitations are there, a lot of people will/can think O/R mapping is not for them and will stick with Datasets.

The hype around ObjectSpaces is dying too, as it seems. If you look at the MSDN site, every 2 days or so a couple of articles are posted about next-gen technologies like avalon, indigo, whidbey etc, not ObjectSpaces. As if its a 'last minute' tool and not that important. This can (speculation) probably be caused by the fact that there are problems with the implementation or that it simply isn't seen as an important aspect of .NET 2.0, however it is important for O/R mapper vendors out there.

By ignoring the fact that ObjectSpaces will be seen as the de-facto standard and its limited focus/featureset, Microsoft kills more or less the interest in O/R mapping. After all, O/R mapping is a technology that is not yet widely accepted, you see DataSets everywhere; when an article describes data-access it's in the far majority of cases about DataSets, not about O/R mapping.

Now, in that situation, if a developer's first experience with O/R mapping is ObjectSpaces, will he be looking for other tools because of the fact he's interested in the technology? I don't think so: or he's happy with ObjectSpaces, or he's not happy with ObjectSpaces and is dissapointed in O/R mapping and returns to typed DataSets and stored procedures.

It's not hard for me to produce a group of templates for LLBLGen Pro which generates code / xml files compatible with ObjectSpaces code/targeting ObjectSpaces classes, so people can use my O/R mapper tool to create the mappings. ObjectSpaces however is too limited: no Oracle for example. Now, a lot of Oracle databases behind websites power asp-websites and these will (are) be ported to ASP.NET. Developers look at whidbey, and think: "we have two choices: ObjectSpaces or DataSets". ObjectSpaces doesn't work with oracle, so the logical option will be DataSets. Do you think they start with "I want O/R mapping!"? No, they start by looking at how they can ease interaction with the persistent storage. Because ObjectSpaces is seen as the de-facto standard (by then) and because it doesn't work with for example Oracle, the developers will opt for the other de-facto standard: DataSets.

It's a myth to think that the majority of developers start by "I want O/R mapping" and then look for tools and then start coding. They think in: "I want to / have to read/write data into/from a database" and because they are spoiled with the n-tier model for years, they think in "DAL tier" and "BL tier". The DAL has to do the persistence work. They have .NET 2.0, and start looking for options in .NET 2.0 to work with data. ObjectSpaces, DataSets... the works. What to choose? Only if they tried them all and have read that O/R mapping really is great and some tools out there offer solutions for O/R mapping for .NET, they'll start looking for those tools. In all other situations, they'll either stick with ObjectSpaces or if that's a dissapointment, will then try DataSets.

So for O/R mapper vendors, as I see it, it's a choice between a rock and a hard place. If ObjectSpaces is great, interest for O/R mapping will grow, however because ObjectSpaces is great and free and already installed with .NET 2.0, why bother buying another tool? If ObjectSpaces is not that great, interest in O/R mapping will die away ("I looked at it, but I don't understand the hype") for the majority of developers and the reason to buy another tool for O/R mapping purposes is fading away.

I really don't know what to do. O/R mapping really needs a lot of positive air-time in the .NET community to gain interest, otherwise it will die a quiet death and will stay the technology of a few people. I understand the propriety API issues that come with every O/R mapper vendor out there, but because Microsoft has made a fatal error by not offering a great, standard API spec like EJB-CMP or JDO to work with, this will not change.

In the end, the average developer will suffer from this, because the amount of choices for O/R mappers all using the same API is not available. The average developer will also not move to O/R mapping instantly, because it is not an appealing technology because of ObjectSpaces' limitations. (or as the head of DotNed (The Dutch .NET user group) described it (not literally): "It's a very complex technology, only use it if you're really interested.")

For the coming 6 months I've decided to write as much positive things about O/R mapping as I can, to make it interesting for a lot more people so when ObjectSpaces arrives they'll not be dissapointed in O/R mapping because of ObjectSpaces but will know that there are alternatives which do produce what they want.

I hope other O/R mapper vendors will follow that initiative so more and more people will get interested in O/R mapping in general.

15 Comments

  • Just some answers:



    ::First of all, the fact that OS is used both

    ::in MBF and in WinFS IMHO show that MS has a



    Since WHEN is Objectpaces used in WinFS?



    Must be new news.

  • If I remember correctly, I got that from Luca's presentation on the PDC, but I'll try to find a good quote somewhere.

  • ::If I remember correctly, I got that from

    ::Luca's presentation on the PDC



    If I got it right, they use the same API and query language, but ObjectSpaces is not really used as engine.



    WinFS is imho NOT built on ObjectSpaces.

  • Objectspaces will limit interest in 3rd party O/R mapping solutions.



    Yes it will, unfortunately.

  • While I don't disagree that MS can kill competition I disagree that ObjectSpaces will result in O/R mappers going away. There is already a growing group of vendors/communities writing O/R mappers. Each one has its pros and cons - which ObectSpaces will have to beat or not be used. For me personally, ObjectSpaces will have to support more databases than SqlServer and Access.



    We really have two classes of developers in .NET - the enterprise developer and the business guy who is developing. This is a huge generalization - but I would consider the business guy lost to MS - unable to explore beyond the namespaces that ship with the framework. What we have to be able to do as developers is sell the best of breed solution to our management, regardless of who the vendor is. It seems we so often fall into the trap of doing the easy thing and just using what is given to us by MS.



    The enterprise guy is someone who reads a blog entry from a company president and is open to giving it a try - even when they have used an MS product for years, or sees a "N" infront of a Java project (Ant,JUnit,etc...) that they have used for years and realizes that it should be tried in .NET, or etc...



    The enterprise .NET community is really growing, you can tell by some of the new sites popping up and better discussions on blogs. We are getting beyond the discussions of how do you drag a table onto a form. This is the group that will use any technology because it is superior - wether it comes from MS, Thona Consulting, or from SourceForge.



    Don't sell the enterprise community short by saying MS will kill O/R mappers. If you develop a good product and put a good face out there it will probably find a market. Maybe the enterprise community can hollar loud enough to get MS to start producing open specs along with their products. Even though there are alot of complaints about the JCP, atleast it exists.



    Mike Doerfler

  • Guys, correct me if I'm wrong, but if the Java O/R mapping scene is vibrant and healthy, surely there'll be no end in sight to porting these same tools to C#, thereby keeping the.Net O/R mapping scene just as vibrant simply because it's so easy to do (porting I mean).



  • senkwe,



    Frans point is that since MS is providing OS for free in the Framework that most people will choose to use that or stick with DataSets rather than buy a 3rd party O/R mapper. I'd agree with that. I don't think we'll see a lot of O/R mappers, ported or created from scratch, once OS escapes....err...is released.



    I think he makes a good point about OS being limited to SQL server. I think that developers that are used to doing O/R mapping using a framework and that need to use !MS SQL as their data store may look to 3rd party tools. But that will be MUCH smaller audience than exists now.



    If I were planning on writing positive articles about O/R mapping, and I may if I can get off my lazy butt and write, I'd take the tact that you end up doing O/R mapping in your code whether you use an O/R mapper or you use DataSets. Show how it's easier to do that mapping using a 3rd party O/R mapping framework rather than in your application code, especially when it comes to refactoring your application.

  • You, of course, are assuming that ObjectSpaces sucks. However, quite to the contrary, ObjectSpaces blows away any O/R mapper currently available (even without any IDE support). OPath queries alone are a huge feature that every other implementation should have supported a long time ago.

  • PS: Oracle, etc. support will come with time (and can be implemented by anyone). 99% of .NET developers are going to be running on SQL server anyway, so it is almost a moot point.

  • You, of course, are assuming that ObjectSpaces sucks. However, quite to the contrary, ObjectSpaces blows away any O/R mapper currently available (even without any IDE support). OPath queries alone are a huge feature that every other implementation should have supported a long time ago. Oracle, etc. support will come with time (and can be implemented by anyone). 99% of .NET developers are going to be running on SQL server anyway, so it is almost a moot point.

  • The "YOU" in your remark, Jesse, is that someone in the comments or is that me? If it's me, you're mistaken, I never assume things and say something else. I never said it sucks, so I don't assume it will suck totally. There are severe disadvantages of using Objectspaces over another O/R mapper tool.



    OPath IS bad. It is not typed, it's strings parsed at runtime, which will result in typo's causing errors you'll only see at runtime (and after testing), while it can be done in a full typed way. I don't know what you mean by "that every other implementation should have supported a long time ago.", because every O/R mapper out there has an object query system using some sort of query language. A lot of them use strings which are parsed at runtime, some use 100% typesafe objects to construct the queries like mine.



    Oracle will not be implemented by a 3rd party, simply because it requires changes to the query engine of objectspaces: it now cranks out SqlServer SQL which is totally incompatible with Oracle and for example sequenced fields require extra information that can't be stored at the moment in the objectspaces files.

  • Whinning that MS "is thus killing businesses" is soooo lame. Write a superior product ( that supports the major RDBMS ...2 DBs is a joke) and there you be quite a few people that will be interested in it.

  • You really didn't get the point of the article, Gheorghe.



    It's about where developers START and where they eventually end up. Perhaps you think developers start with Google and search for "The" best tool, but most developers start with the MSDN docs and vs.net and only if that truly fails they'll look for something else.

  • Actually Gheorge, LLBLGenPro is a superb product (and Frans didn't pay me a dime to say that!). Support for SQL and Oracle is great and not a joke at all, given their marketshare in the PC environment. You want support for tens of databases, go pay your $100 000+ to someone...



    Further comments: O/R mappers are not just for enterprise shops. My small dev shop is benefitting greatly from using LLBLGen, as I am sure are other more lateral thinking businesses, employing O/R tools right now. Geez, O/R mappers save so much time, the benefits are immense.



    I certainly won't be jumping over to MS OS V1 when it eventually arrives, as long as tools like LLBLGen are delivering the goods TODAY.



    Don't give up Frans!!! (...or Thomas, or any of you other guys doing great work)

  • Hi John! :)



    We won't give up, don't worry :) O/R mapping is a great technology, and once you've used it, there is no way back :)

Comments have been disabled for this content.