I'd like to write a
regular .NET column - a real one, in real media [1], not just in my blog.
Either online or in print.
If you are an editor
reading my blog and interested in me writing a monthly column for your magazin
or portal, please drop me a note.
Credentials: I'm a
professional author; have written two books and a number of articles
- and I'd like to share both, opinion and experience about .NET
applications and enterprise-level application design. Some more reasons why
I'm the right one to write a column about these topics can be found at here.
I'm mildly annoyed
by constant comparison of .NET vs. Java by folks who don't know the truths about
the respective other environment. I read a nice statement the other day
which was similar to "Maybe .NET developers should look into Java. Nearly
everything which is available there minus EJB is quite similar."
I absolutely second
this. But I'd like to go a step further: "Maybe Java developers
should actually look into .NET. Nearly everything is quite similar but
ASP.NET and Windows Forms could give you a different view about programming
in these environments." Is it a better way? Is ASP.NET better than JSP?
Well -- at the end of the day, the answer is of course "it
depends". Whenever you read a statement similar
to "ASP.NET is better then JSP" (or vice versa) you should really
take a step back and look at the author's credentials. It might be the
case that they actually never ever did a real project in the other environment.
There simply is no definite answer to this question. It always
depends.
But still -- no
matter which one is "better", I'm going to tell you a sad truth: Neither my
customers nor most developers care about syntactic sugar like property
accessors in C# vs. getSomething and setSomething in Java or events in .NET vs.
callback interfaces in Java. I'll even go as far as to say that my clients
usually don't care about JSP vs. ASP.NET. They might not even care about the
associated implications on long-term maintenance and developer productivity
[1].
But what DO they
care about? Experience & availability. Both for developers, project
leads and sysadmins. Chances are pretty high that in corporations with a number
of MCSEs and Microsoft developers, the next step will be ASP.NET and Windows
Forms. If however, your customer's business currently runs on Sun Enterprise
15000 machines, you won't see them switch to .NET in a number of years to come.
Why? Because they don't have sysadmins capable of running these systems, they
don't have developers capable of implementing these solutions, and they don't
have project leads capable of estimating the efforts associated with a .NET
solution. And -- maybe the biggest concern -- they simply don't
have the
money for ditching their Sun E15K in favor of a equally or more
potent ProLiant. And
even if they did -- do you really think that they would render their
hundreds of thousands of lines of Java code obsolete and throw them out of the
window? Well, these times where money didn't matter are long
gone.
Instead of trying to
prove to your client (or department, or company) that .NET is "better" than Java
by creating lists of points why X is better than Y, I propose a different
approach which suits equally well for Java developers and for .NET developers:
Interoperate. Maybe you didn't follow the news quite recently, but there is such
a thing called SOAP 1.1 which allows you to actually interoperate between the
two environments [2]. If you're a Microsoft developer at heart who's working in
a Java shop, simply try to sneak in a Windows Forms tool/application. Call your
existing Java business logic by means of a web service and show
them that it works. Then we can finally sit back from all these
discussions and again start to pick the tools which are right for the job at
hand.
My name is Ingo
Rammer, and I'm a Microsoft developer. I just happened to spend some years
in the Java camp as well.
[1] I don't know if
you agree, but I definitely think that a seasoned Java developer is actually
more productive with JSP than a newly trained ASP.NET developer in his
environment. [2] And no, this isn't marketing BS. It really works.
It's just XML. It's just data. There's actually very little which can
go wrong.
Currently, the
oversimplified not really practical basic remoting is supported. I
recall Miguel saying that a SOAP serializer is either done or mostly done
(maybe only in CVS) and that someone has just finished binary serialization
for remoting.
Also - why is [Serializable]
an attribute while MarshalByRefObject is a
base class? The arguments I've heard are pretty weak. As
Mike Woodring points
out, deriving from MBRO means inlining of methods has to be disabled.
And who derives from MBRO? EVERY SINGLE class in the Winforms
hierarchy.
As someone
who spent a good six months of his life inside the Remoting stack, I
certainly do have an opinion on this. At the beginning, I definitely thought the
same way. Why the heck didn't they implement yet another attribute for
designating an object as a remoteable one? This way, I could easily later flag
classes deeper down in my class hierarchy to be remoteable. And that's the very
answer as well. This just isn't possible.
Let's say
you have the following method:
public void foo(bar x) { x.baz() }
And
you have an inheritance hierarchy of [System.Object]<-[bar].
In this case, the JIT could inline the call to baz().
If you'd use attributes to designate MarshalByRef
(or "proxyable") semantics, you could then extend the hierarchy: [System.Object]<-[bar]<-[foobar]
and flag foobar with this attribute. Bad thing. The JIT now must not inline
the call to baz().
The only possible way to
solve this is to have
[System.MarshalByRefObject]<-[bar] because
this way, the JIT knows right from the start not to inline the call to baz() and
everything will be fine.
Still - why does
every class in Winforms inherit from MBRO? Well, MBRO also conveys the point
that "it doesn't make sense to ever marshal me by value." This
basically means that the object is somehow bound to a resource on a single
machine, like an hWnd for example. So much for Windows Forms
[1].
I however also remember a discussion with
another speaker at one of the conference (not sure if it was Mike or Peter) in
which we were talking about our opinions that the name
"ProxyableObject" would have been better to convey the correct meaning.
Heck, it isn't about marshalling by reference - it's about proxying.
And no, I
don't think that these are the same things. A MarshalByRefObject would have to be proxyable but any
random proxyable object could just exist without any marshalling at all. I could
simply create a proxy (i.e. a custom RealProxy), flag
my class with a ProxyAttribute and see: I get a
proxy instead of a real object whenever I create a new instance of the
class.
So in fact,
ContextBoundObject should have been called
CustomProxiedObject. It's not about contexts - it's about an object
supplying its own proxy. Creating or checking contexts is just the work of one
very special kind of proxy. It could do many more things - like simply
intercepting method calls and providing for some AOP semantics.
[1] Weird
idea: maybe that's a good thing. You are normally supposed to check ctl.InvokeRequired (and if true, use ctl.Invoke() instead of directly manipulating the UI)
when working with multiple threads. You could write a simple, generic proxy
which you could use in front of any GUI control, and which would do this for you
automatically whenever you call any method or access any property. Hey, just
talking about getting rid of some
code.
Will I ever
"switch" to Linux/Mono? No ... seriously, I really like Exchange server
- but you already knew
this. Actually, Exchange is just a sample: From my general experience,
it's simply easier to interop with different applications and servers when
running on a Windows box.
Oh, and yes, I know
that there are people who fear "data-lock-in" when using Microsoft
products. My opinion on this topic is a little bit different. I believe
that whenever someone tells you something like this, you
shouldn't believe him too much but instead try for yourself. Actually,
there are few (if any) products in the Microsoft space which don't either offer
the necessary APIs to access your data or for which there aren't XML
based means to access it. This fear of lock-in mostly comes from people who
never worked in this space. Fear is a sign of nescience. This is
however not only true for the open source folks. I know quite a number
of guys on my side of the fence who fear Linux and open source software in a
similar way.
Don't fear it - use
it. That's the only way which allows you to judge for
yourself.
C# is done, VB
is 70% done, and JavaScript is 50% done. This is good. Miguel
demonstrated an almost unmodified version of iBuySpy that was only
really slow because it was connecting to an MSSQL server in Spain over
802.11b. In theory, you could write an ASP.NET web application today and
deploy it on a Linux server using Mono. [...]
Overall I was
impressed by the state of Mono and the demos. It's awsome to be able to
take a Microsoft demo app out of the box and run it using
Mono.
Wow. That sounds
pretty serious. I guess I actually have to fire up a VMWare to install a recent
Linux distribution on it and play a little. Anybody knows about the current
state of ASMX support on Mono?
From the
"While you've been in bed"-department: Clemens is working
on"a pretty radical
extension for Enterprise Services and COM+ - it's actually
more a "newfeatureset"
than a tool or wrapper.". I
really hope that he succeeds at squashing the GC related bugs.
For those who dare to know, let me rephrase Clemens [1]: we're talking
about interception similar to IMessageSink, but this time for
EnterpriseServices. And no, you won't need a new version of COM+ and no, you
also won't need a new version of .NET or Windows. It seems as if support for
this kind of functionality is already available. But as Clemens puts it: it's
writing code based on analyzing hex-dumps.
If you just
wondered ... yes, Clemens rocks. Hacking things like this is
just a slight little bit above my knowledge: while the tough
guys played C++ and COM in the 90s, I did VB and Java. On the other
hand, there are actually very few things which make me regret this -
it's just that Clemens' EnterpriseServices extension is certainly one
of them. It's so hard to realize that there are things in a technology (which
you otherwise know pretty well) which you'll never fully understand
[2].
[1] Hey, I'm not saying
anything more than he already did. I promised. [2] Oh yes, I've seen the
source. And it sounds pretty reasonable when Clemens explains it. I however
still don't understand it at a level which would allow me to re-create or even
start re-creating it - and I quite likely never will. I never knew the
glory days of C++ ;)