> I've been developing applications using Microsoft products
> for many years and with the .Net framework for 2+ years now.
> I've been keeping an eye on the features that are supposed to
> be included in Longhorn, VS.Net and the framework. It's what
> is don't see mentioned that disturbs me. IMO, there are some
> noticable gaps/oversights in what MS is promising in the near
> future that will affect my decision to use keep using their
> development tools.
You're not alone.
> 1.A replacement for COM+ services. It seems to me that a
> first-class, .Net- based not COM-based, highly-scalable set
> of component services is very much needed to build
> applications on a par to that which can be created in other
> frameworks (namely Java). In order to create these OO
> applications we need a comprehensive set of top-notch object
> services (not an ADO.Net Transaction object in a Data Access
> block or a wrapper around COM services).
You mean something like the EJB framework? The problem with this
is that the services are a core component of the operating system. This
makes it impossible to replace it with something managed and makes it
automatically a subject for re-use in a managed environment: after all,
why re-implementing an EJB like framework if you already have one.
I agree that COM+ is now not that usable in .NET: you have to
inherit from System.ServicedComponent, while it would be more consistent
to supply an interface you have to implement to be able to participate
in COM+ transactions; .NET doesn't have MI so mixin classes are
impossible once you have to inherit from ServicedComponent. AOP can help
here in a great deal.
> 2. .Net is all about OO application designs. However, this
> paradigm really falls apart when it gets to the data tier
> because, again, a first-class Object Relational Mapper is not
> available out-of-box. I know that there are 3rd party
> solutions for this, free and not free but, come on, a company
> with Microsoft's $$ should at least supply a very decent ORM.
I don't see why they should supply an implementation. I more
want a general specification like JDO or EJB-CMP so every O/R mapper can
implement these specs (eventually with the help of some generic base
classes/interfaces) like which is the case in the Java world.
The big problem with an implementation is that the
implementation becomes the 'general specification' while it is just 'an'
implementation, if you don't have a general spec.
Microsoft apparently thinks that by supplying Objectspaces and
MBF for free (because they use these for internal products anyway) the
average developer will be very pleased and it truly adds something to
the value of .NET. I think this is a mistake. The average developer is
far better of if .NET has a general specification like EJB-CMP and for
example JDO. The reason for this is that the developer then will be able
to swap tools if they have to and can pick the best implementation of
the spec. Now every O/R mapper has its own specifications, own object
query language, own flaws and strong points and this is also true for
Objectspaces.
The idea to have a general spec for this in .NET is not new.
Yours truely and others (Thomas comes to mind) have mentioned this
already in the closed beta newsgroup of objectspaces in 2003 when
whidbey alpha just started (august 2003 if I'm not mistaken). Not a
single word was received from Microsoft on this idea.
It's this lack of feedback from Microsoft which is the truly sad
part of the story. There is no dialog, yet Microsoft is working hard to
give the developer Objectspaces without a general specification like
EJB-CMP or JDO. And once the implementation is there, a general
specification is very hard to get accepted.
In other words: if Microsoft isn't releasing a general
specification ala EJB-CMP or JDO for .NET with whidbey (and it looks
like they will not do that at all), .NET developers will never have the
joy of a common general specification for persistent objects, which only
brings benefits to the table. (For the people who think a 'standard
specification' brings trouble too: correct, but at least then there is a
standard all tools will adapt; stuff not mentioned in the standard
specification will be added by the various tools themselves). Microsoft
can even peek in what's already been defined for Java for years: the
EJB-CMP and JDO specifications. They don't have to make the mistakes Sun
has with the standard, they can weed through the various feedback java
developers have given during the years on these standards and adapt
these too.
It would have been a win-win situation. I really fail to see why
Microsoft is so stubborn not to release a general specification for this
important aspect of .NET.
> They can jack up the price of VS.Net Enterprise if they did
> this and I doubt anyone would care. I realize that
> ObjectSpaces is intented to fill this obvious gap but what
> I've read about so far it seems like another somewhat hokey
> attempt to give us "something" but nothing really useful.
Correct. Although Objectspaces is not that bad, it is just 'an'
implementation, and every flaw in the implementation is automatically a
flaw in the 'standard' it is about to set. Like the schema definition
used for objectspaces is not suitable for databases with solely schemas
and not catalogs (like oracle) nor is the architecture pluggable so for
example Oracle can write its own dynamic query engine for Objectspaces
based on ODP.NET.
> 3. If Microsoft doesn't want to undertake these development
> efforts let 3rd parties do it. Why doesn't Microsoft create
> specifications/open up parts of the framework so that 3rd
> parties can create, pluggable components to fill these
> obvious gaps ASAP. Then at least we'll have choices as developers.
The idea has crossed my mind, but it will be a lot of work and
in the end it still will be a 3rd party spec which will never be THE
standard set by Microsoft. Mind you, by far the most developers using
.NET simply look at what's offered by the framework first, and only the
few who can think out of the box will look further.
Why Microsoft isn't releasing a general spec is also for me a
thing I can only guess about. I think it's along the general design
aspects of .NET, which has in no area a general open spec. and only in
some areas (where Microsoft needed flexibilty) the ability to 'plug in'
your own code. A lot of technology in .NET is either the Microsoft way
or the Highway (i.e. you have to build 99% by hand). This can be a good
thing in a lot of cases where teh Microsoft way is sufficient enough.
However in the areas where it isn't you're in trouble. For example, if
you specify an event handler in a class, you suddenly have to fully
implement ISerializable if the class was just marked with [Serializable]
to keep it serializable. Pretty weird design, but nonetheless reality.
> I realize that no development platform is perfect. Does
> anyone have any hints as to if Microsoft realizes that there
> are problems in the tools they are providing/not providing
> and what they are planning to do about it? I can't believe
> that they don't. Opinions?
I don't WANT TO believe that they don't but I haven't seen any
evidence that they do (except the SOA related material which will be
addressed in Indigo), more and more I start to believe that they
actually don't care what's about to happen in the persistent object
corner. For some time now all hype, feedback and information about
Objectspaces has ended. The few people asking questions in the
Objectspaces newsgroup don't get replies anymore. I'm guessing here, but
I have the feeling something is going on related to objectspaces but
history tells me it's not going to be something we want (like a general
specification, only a set of base classes to help implementing the spec,
etc.)
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.
Frans
--------------------------------------------------------------------
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
