> > > 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.
>
> Sorry, POJO is Martin Fowler's joke on this point: plain old
> java object. On EJB-CMP, substantial numbers of users have
> bailed on the idea. Among best practices for using J2EE, many
> recommend not using entity beans. My point isn't to discuss
> the merits of EJB, but to question the assumption that by
> beginning with a spec and a reference implementation, a good
> platform will be developed.
it of course isn't guaranteed, as is using open source not a
guarantee for secure software. The point I was trying to make was that
if NO spec is made, which is the case for .NET, the rough implementation
pushed forward by the platform developer (Microsoft in this case) will
be seen as 'the standard' because there is nothing else. Would there be
a specification, it could be used by tool vendors to commit their tools
to, which would benefit the developers using these tools instead of
working against them. That doesn't mean the spec is the only thing the
tools should support, of course not :) The tools should, and will,
support extra features to make them more appealing than the competing
products. However the core aspects should be standarized. I mentioned
EJB-CMP, because, as I understand it, it's a framework to persist
objects, as in: it defines specifications to go forward with persisting
objects. It is my understanding, but I'm no expert on EJB-CMP, that any
O/R mapper vendor can adapt this specification and if it does, the
developer can use generic code which uses the EJB-CMP principles to get
his objects persisted using the tool which adapted teh EJB-CMP spec.
Now, if the developer wants to use another O/R mapper, because that
other mapper has a unique feature he needs, and that mapper also adapts
the EJB-CMP spec, the mapper can be hooked into the application, and the
developer doesn't have to change a single line of code in hte code
already using the EJB-CMP mechanisms to persist the objects, PLUS the
developer already knows the query mechanisms, the overall mechanisms to
get stuff persisted etc.
That's the kind of flexibility you'll get when a generic spec is
in place. There will be always areas in the spec which will be food for
debates, that's embedded in the nature of a spec :). However I doubt it
if we're better of without a spec than with a spec. True, a very bad
spec is working against you, but this isn't new territory, it's really
old tech, a spec can be written today without the mistakes others have
made in the past.
> > > 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.
>
> Object queries, large data stores, having to implement
> abstract classes, interfaces, skill sets, source of
> meta-data, many more things are currently all done quite
> differently by each implementation. EJB-CMP chose a model
> that hasn't been as widely used as I would imagine Sun had
> hoped. All things things represent design tradeoffs that are
> very hard to answer in the general sense.
hmmm. I wonder what the real reasons are for not being able to
commit to a spec like the EJB-CMP. I more and more lean to the idea that
politics and stubborness are causing this instead of a large set of
flaws in EJB-CMP. As I said before, persistence of objects is a
dead-simple technique and is pure overhead. As Ralf Westphal brilliantly
described in his blog
(http://weblogs.asp.net/ralfw/archive/2004/02/04/67262.aspx) a lot of
people expect the O/R mapper to solve things it shouldn't try to solve.
If you as a developer expect the O/R mapper and thus the spec it
implements to solve problems it simply can't or better: it shouldn't,
the spec falls short and the O/R mapper implementing it is not
sufficient, which can lead to the conclusion the spec is wrong/bad and
not useful.
Which isn't, IMHO, in sync with reality. At the moment, and for
a long time to come, it is hard in .NET to write a 100% failproof object
cache which is usable in multi-machine-multi-appdomain environments. It
is my understanding that EJB-CMP does support a mechanism for
multi-machine-multi-thread object awareness, which means: an object O in
thread T on machine M can and will be seen by another thread U on
another machine N. It might cost some overhead, but without it, any
claim of a safe cache is false: you still can have a situation where on
2 threads on different machines the same entity is loaded and one is
saved and the other isn't and is recycled through a cache, not aware of
the fact that the data inside it is actually out of sync.
It's these kind of mechanisms which should be added to .NET,
even in a raw form, together with a spec, which make it possible for all
toolvendors to write a cache system which does work in all cases.
> At this point, a product can take a stand, here is how we do
> it, and then users can choose a product with the tradeoffs
> least painful to accept. A complete spec by MS at this point
> would force a set of tradeoffs that may not hit a large
> enough base of users.
I firmly disagree. Now there is NO standard. If you only look at
a couple of O/R mappers for .NET and how they query for objects, you'll
see there is not a single one who even looks a bit like another one.
Also, there is no foundation for cross appdomain/cross thread object
awareness, there is no general framework the O/R mapper functionality is
'placed into'.
A spec is limiting you to a set of tradeoffs, you can always add
that as custom functionality. Apple has a framework with spec, Sun has
EJB-CMP with spec (and already a couple of revisions) and a lot of
implementations for several years, there are a lot of O/R mappers out
there for Java for a couple of years already, and for .NET ditto. If an
organisation like Microsoft can't formulate some sort of spec for the
raw services a persistence framework has to offer, what can? 3rd party
vendors with their own propriety frameworks which are totally
incompatible with eachother? I don't see why that's beneficial for the
developer.
> > 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.
> >
> What about a smaller set of specs? What would be the least
> amount of specifications you would deem useful. Actually, an
> object query language would be one of my first choices, with
> some relativley simple specs on how to call the query
> processor, interfaces for the results. Perhaps an
> implementation that would work on generics.
An object query spec is important, as it is one of the first
things the developer using the implementation of the spec will see and
will use the most. Another, far more important one, is the way the
persistence functionality is added into the general .NET framework. The
big problem with Objectspaces as an implementation is that I can't
extend the query language, I can't add my own query producing engine, I
can't add oracle support if I want to, I can't add object awareness out
of the box so a safe cache can be written, I can't make persistence more
transparent than it is: like in EJB-CMP where the container, as far as I
know, deals with persistence, you just plug in what's necessary.
Objectspaces is as closed as any other 3rd party persistence framework
is, even more closed as it doesn't generate any code, so you can't alter
templates to get different code, nor can you override any classes to
plug in your own mechanism via a strategy pattern.
It's that kind of general flexibility that's missing in .NET,
when it comes to object persistence functionality. I wouldn't mind a set
of smaller specs with just raw implementations where developers and 3rd
party tools could build upon. Now it's Objectspaces or DoItYourself.exe,
without any hope for an open Objectspaces framework that's fully
adaptable to your own needs AND no spec which would make life easier for
the developer.
The question then arises: why not produce the spec yourself,
together perhaps with some other 3rd party tool vendors. Answer:
Politics and the question what to include? Everybody already has an
implementation. Who will control the spec? Because everybody already has
an implementation of some specification, they all want their spec to
become their spec so they don't have to invest money to alter their
code. I.o.w.: this will not be leading to a solution. The only solution
here is if the platform developer provides a specification, that is: a
true spec AND a set of raw services to make implementations of the spec
easier plus offer functionality to be able to 'hook' your implementation
into the framework seamlessly.
It will probably always be a question unanswered why Microsoft
chose for the crippled implementation route and not the spec first -
implementation later route. However I have the feelilng they will regret
this choice later on, as object persistency will be more and more become
important to developers and it therefore will demand a solid foundation,
something a crippled implementation can never give, however a theoretic
specification will.
Reading the newsgroup replies about objectspaces I have the
feeling microsoft also doesn't have a specification in full yet what
objectspaces has to do. ("We're thinking of adding that..." is a
sentence I've seen multiple times in the last couple of weeks) Perhaps
there is room for improvement, who knows, however I'm not that
hopeful.....
FB
--------------------------------------------------------------------
Get LLBLGen Pro, the new O/R mapper for .NET: http://www.llblgen.com
My .NET Blog : http://weblogs.asp.net/FBouma
--------------------------------------------------------------------
===================================
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
