This post originated from an RSS feed registered with .NET Buzz
by Jonathan Crossland.
Original Post: Where is the power emphasis in Whidbey
Feed Title: Jonathan Crossland Weblog
Feed URL: http://www.jonathancrossland.com/syndication.axd
Feed Description: Design, Frameworks, Patterns and Idioms
When it comes to everyday business applications, where the need for Reflection and dynamic creation and execution of types is obviously not so great, I can understand that Whidbey may not correct the performance issues.
However, I thought that a large percentage of the power of .NET comes from the fact that it is Object-Oriented, that it exposes things like reflection, message sinks and from web services creates and invokes types over the wire.
Remoting, MarshalByRef (or ProxyableObject) is powerful.
Some things are nothing new, as reflection in Java, but finally in our arena, in a proper framework, we got it.
My question/comment is this, we have known that this area (Marshalling, Reflection, Types, Invoke) has performance problems, but this a core problem!
Does this not take away from .NET's power and render many of these aspects useless in the enterprise, especially in run-time?
Is it correct in saying that from MarshalByRef upwards we have a different, slower system?
Is it correct in saying that from GetType() upwards we have a different, slower system?
The point can be summarized like this:
We can write methods, use early binding and create simple applications efficiently, which is pretty quick in .NET. But we can do that anywhere!
The real power though comes from Reflection, marshalling, Attributes, delegates, and so forth, which is slow (especially from reflection pov).
In my opinion the future of the .NET Framework is in two areas,
Increase the library and base class functionality for RAD scenarios (moving ahead in Whidbey)
Provide mechanisms (at no performance deficit) for allowing developers to choose the architecture - AOP, SOA, OO etc (moving ahead in Whidbey - only for SOA??)