> > By the time Objectspaces is released almost all O/R mappers
> > currently on the market will have all the objectspaces features and
> > more. They all also will suffer from the same flaw: there is no
> > general specification, every tool has its own specifications, it's
> > hard for a customer to swap tools for a specific requirement etc.
etc.
> > I really really fail to see why that is in any advantage of
Microsoft,
> > because it will only be a big burden for developers which can truly
> > hold back .NET's acceptance in the industry where Java is already a
bigger player.
>
> Is it really that clear that a general specification of OR is
> a good idea now?
> OK, so it's clear you think so and you have given it a lot of
> thought. But having lived in the java world for some time
> before becoming a .net developer, the general specification
> approach has not proved that successful either.
I think it needs research to find out what the real cause is for
that apparant failure. To me it's very clear that Java has one very big
advantage over .NET and that is that there ARE a set of standards for
EJB-CMP and JDO. All O/R mappers for Java support these standards. I
don't see why this then can be interpreted as 'not successful'.
> Unless the the problem domain is perfectly understood, the
> specifications become a hindrance, a barrier to progress.
> EJB is probably as good an example as any. The goal was
> sound, the attempt made by lots of smart people, and the
> result, though implemented by a few key players, has had it's
> share of issues.
of course it has, every standard has drawbacks in some area's.
That's also why I said that Microsoft should listen to the feedback
ventilated by a lot of java developers about these standards so
Microsoft understands in which direction these standards should be
evolving.
But nevertheless, it will be a standard. Every O/R mapper will
adapt the standard like it is done in Java-land. This will result in a
far more open market for tools and a far more appealing market for the
developer: every tool supports the standard, he then thus knows what a
tool at least can do and more important: HOW the developer can utilize
the tool.
> Now the java world is considering radical ideas like POJO as
> an alternative ;-)
Seriously: I doubt it. the EJB-CMP specs (especially the latest)
is very solid. You can pinpoint to new technologies all you want but
.NET hasn't an equivalent of that spec anywhere in sight. And again: an
implementation should never be a 'standard' definition, so Objectspaces
should never be seen as 'a standard'. It also can't be a standard, since
it has design limitations which can be a burden when you want to support
other databases, like Oracle.
This last aspect is not in the interest of Microsoft, in fact,
Microsoft will do everything it can to make Oracle have more sales
because of .NET, and this is logical behaviour as Oracle are their
competitors. It also makes an implementation like Objectspaces useless
for defining a standard for other O/R mapping tools. This is very very
very sad and counterproductive for the average developer in the field.
For the people who think otherwise: Imagine you are a contractor and you
have to develop an ASP.NET webapplication on Oracle (Oracle is used a
lot today to power normal asp sites, which will be rewritten eventually
in .NET sites). You've learned Objectspaces in a previous job and are
now ready to start this new job. However, Objectspaces doesn't support
Oracle, so you're forced to pick one of these options:
1) use datasets
2) pick a 3rd party O/R mapper tool
3) ask the client to dump oracle for Sqlserver
1) is not an option once you've worked with O/R mappers. 2) is at first
a normal decision. But it also has a problem: this 3rd party O/R mapper
most likely has a total different object query language, works
differently with objects etc etc. This will thus force you to start from
scratch with this new tool. Would there be a standard, this wouldn't
have happened. 3) is what Microsoft wants you to do. It's their right to
do so, they too want to make money after all :). 3) is however not in
the interest of the developer, as he can most likely loose his
contractor job to someone else who can work with the 3rd party tool.
This is a story not a lot of people want to hear, I'm aware of
that, however it IS reality.
> In the case of OR tools, I don't think there is anywhere near
> enough consensus on how to do it to implement a sane spec, do
> you?
Why not? I found the EJB-CMP spec nice, sometimes a little
farfetched but overall very good. O/R mapping is pure overhead code,
it's there because an OO paradigm requires translation to a relational
model to work. A lot of people make this a very hard to understand thing
but it is in fact very simple: class.Field is stored in table.Field.
whoa, that's hard :) Now, the fun begins when you start talking about
how this mapping is accomplished. I mentioned the direction class.Field
-> table.Field. However what if: class.Field <- table.Field? At first
this seems the world upside down, but it's about the same thing, you
just pick another anchor to lead the design, that's all: be it the
relational model (in abstract form like NIAM/ORM) or the class
hierarchy. A german blogger, Ralf Westphal wrote an article about this:
http://weblogs.asp.net/ralfw/archive/2004/02/04/67262.aspx
A good spec only defines the core services that have to be
provided and I find EJB-CMP a good example for that. A tough issue will
probably be the object query language, however that too will be a minor
point in the end: there is always something to gripe about: be it not
type safe or be it too verbose or other things. As long as the spec
offers extensibility, it would be great.
At the moment we have NOTHING. With objectspaces we get
something, which is close to nothing, because it is not usable in an
environment with another database or when you don't want a non-intrusive
approach (i.e. you want to bind your classes to a grid later on, happy
coding :)).
> And if MS, or an outside party took a stab at it, and
> the result was anywhere short of perfect, wouldn't they take
> every bit as much heat for it, and suffer yet another legacy
> issue to absolve themselves of, than they are receiving for
> not doing it now?
Why? Now there is NO spec, NO work done to deliver a general
spec, just a crippled implementation of an O/R mapper which gives
problems like I gave an example of. Even if the spec is not perfect, at
least there is one, a 3rd party tool vendor can always fall back to own
specifications as extra offerings, like they do NOW (like a second
object query language).
> If you look at other areas where api specs have been written
> the results are equally uncompelling, though each has had
> some important hits. W3C? OASIS? OMG?
The W3C is a bad example, as their spec is not implemented
correctly by the biggest player (and member of the W3C): Microsoft,
which just follows behaviour Netscape has showed for years. I'm not
familiar with the other acronyms you mentioned.
I really fail to see why a solid spec would hurt anyone.
FB
===================================
This list is hosted by DevelopMentorŪ http://www.develop.com
Some .NET courses you may be interested in:
NEW! Guerrilla ASP.NET, 26 Jan 2004, in Los Angeles
http://www.develop.com/courses/gaspdotnetls
View archives and manage your subscription(s) at http://discuss.develop.com
