Request for comments about using the .NET Component Model in C#

[James A. Fortune]

Although I've never programmed in VB.NET, this past week I read the
following book:

Visual Basic .NET Reflection Handbook
Wrox Press 2002
ISBN 1-86100-759-0

It basically extols the dynamic linking that Reflection allows. I
read it in the hope that its concepts could mostly be carried over to
using Reflection in C#. P. 16 states:

"In other words, we've just found a limit of the late binding provided
by VB.NET. If we want to select a method that can accept a particular
kind of object based on its 'runtime' type, overloading doesn't
provide a good mechanism for it, because overload resolution uses the
compile-time type. In fact, there is no syntactic mechanism to
reliably do what we want. What we need, in order to do this, is
controllable late binding. Reflection provides this ability to take
complete control at runtime of what code is executed."

After showing ways to examine Metadata, mostly through the
System.Reflection and System.Type classes, it contrasts invocation
through Reflection with invocation using Delegates before continuing
on to dynamic invocation and dynamic creation of objects through
Reflection.

P. 100 states:

"The developer can design an architecture that can easily be expanded
and extended without redevelopment, and in some cases can be added on
the fly without recompiling the original source code."

That concept was straightforward and easy to understand, although it
would be nice to know how prevalent the use of that technique is.
Then it shows how to use the Abstract Factory Pattern to assist in
loading assemblies dynamically. Next it shows how to implement
standard and custom attributes. The coup de grâce (the final chapter)
talks about the System.ComponentModel namespace and how it enables
creating custom collections and enables greater programming
flexibility. After looking at the documentation on MSDN for the
System.ComponentModel, I see that it is relatively vast. Now for my
question! Can someone who uses that namespace give me an idea of what
kind of programming flexibility I can hope to gain if I wade into it
compared to what I get using more commonly used namespaces?

Thanks in advance,

James A. Fortune
(e-mail address removed)

You have to be able to learn things from everybody. However, you
learn more from those who are better at things than from those who are
not.

 

[James A. Fortune]

[...]The coup de grâce (the final chapter)
talks about the System.ComponentModel namespace and how it enables
creating custom collections and enables greater programming
flexibility.  After looking at the documentation on MSDN for the
System.ComponentModel, I see that it is relatively vast.  Now for my
question!  Can someone who uses that namespace give me an idea of what
kind of programming flexibility I can hope to gain if I wade into it
compared to what I get using more commonly used namespaces?

I'm not sure you'll get exactly the answer you seem to be looking for.
That is, a connection between Managed Extensibility Framework (MEF) and
dynamic overload selection, as well as a strong reason to use the latter.

As far as the System.ComponentModel namespace goes, it's used
extensively throughout Forms and WPF programming.  Lots of support for
things like observable collections and data conversion.

They added a bunch of children namespaces, in which you can find stuff
to support MEF, which is the new(er) .NET "plug-in" API.  It wraps a lot
of the dynamic assembly loading implementations that one might have done
before to do what you're describing.

In the real-world, it is not really very common to need to dispatch
different methods based on the specific type of an argument.  What are
more common scenarios are for the design to include polymorphic types to
allow static typing to work and yet get different run-time behaviors,
and for generic types and methods which allow the same code to be used
conveniently where the specific type of the argument doesn't matter.

Of course, to some extent that may be because the language strongly
supports such scenarios, and doesn't offer much in the way of dynamic
dispatch.  Note, however, that C# 4.0 (released last Spring) does
include the new "dynamic" type, which can do a lot of what you're
talking about (and in particular, offers a similar sort of late-binding
that the "Object" type in VB.NET has always offered).

Note that even the MEF and other reflection-based dynamic dispatch
techniques still usually rely on polymorphism.  That is, they aren't
generally inspecting the parameter types and selecting methods to call
based on that.  Rather, one declares an interface implemented by the
plug-in code, and then just calls to the interface.  Polymorphism takes
care of the run-time-dynamic behavior.

Pete

Thanks for your explanation. I wasn't really looking for a particular
answer, just understanding. I suspected that later versions of C#
might have improved ways of binding dynamically. I will be mostly
bypassing Forms programming in favor of WPF despite some of WPF's
idiosyncracies, but I'm still likely to need to do a lot of data
conversion, so perhaps I'll look into the System.ComponentModel
namespace when data conversion is required. I really like programming
to interfaces because that is more intuitive to me. I like the
flexibility that late binding provides when programming databases, so
I will definitely want to check out C#'s new dynamic type capabilities
for late binding. If polymorphism can extend the runtime generality
of the interface, I'm satisfied with that. I haven't done lots of C#
programming yet, so the new paradigms are relatively easy for me to
adopt. Right now I'm trying to decide on an overall C# programming
style and your explanation is helping me decide which techniques
should receive the focus my energy. The kinds of problems I expect to
face also help shape that focus. Your comments about standard
practice are valuable because most instructional material doesn't
convey the true relative usefulness of the various techniques taught.
So far, my overall programming style has been a bit unorthodox, but
hopefully that's the result of trying to have good reasons for doing
things a particular way . For example, my preference for dealing
with exceptions is to check a condition whenever it's possible to
check that condition and to reserve the exception for the case where
the condition has changed within the small amount of time between when
the check was made and when the attempt is made. I don't malign
others who don't do it that way, especially when that decision
produces more concise code, because they had a reason for doing it
that was thought out in advance. This NG is helping me make those
kinds of programming style decisions that should serve as a foundation
for solving most of the kinds of problems I expect to face. Later on,
if some new problem presents a challenge for which my programming
style is unsuited, I can live with having to learn a few new tricks.

Thanks again,

James A. Fortune
(e-mail address removed)

 

[Arne Vajhøj]

Although I've never programmed in VB.NET, this past week I read the
following book:

Visual Basic .NET Reflection Handbook
Wrox Press 2002
ISBN 1-86100-759-0

It basically extols the dynamic linking that Reflection allows. I
read it in the hope that its concepts could mostly be carried over to
using Reflection in C#. P. 16 states:

"In other words, we've just found a limit of the late binding provided
by VB.NET. If we want to select a method that can accept a particular
kind of object based on its 'runtime' type, overloading doesn't
provide a good mechanism for it, because overload resolution uses the
compile-time type. In fact, there is no syntactic mechanism to
reliably do what we want. What we need, in order to do this, is
controllable late binding. Reflection provides this ability to take
complete control at runtime of what code is executed."

After showing ways to examine Metadata, mostly through the
System.Reflection and System.Type classes, it contrasts invocation
through Reflection with invocation using Delegates before continuing
on to dynamic invocation and dynamic creation of objects through
Reflection.

P. 100 states:

"The developer can design an architecture that can easily be expanded
and extended without redevelopment, and in some cases can be added on
the fly without recompiling the original source code."

That concept was straightforward and easy to understand, although it
would be nice to know how prevalent the use of that technique is.
Then it shows how to use the Abstract Factory Pattern to assist in
loading assemblies dynamically. Next it shows how to implement
standard and custom attributes. The coup de grâce (the final chapter)
talks about the System.ComponentModel namespace and how it enables
creating custom collections and enables greater programming
flexibility. After looking at the documentation on MSDN for the
System.ComponentModel, I see that it is relatively vast. Now for my
question! Can someone who uses that namespace give me an idea of what
kind of programming flexibility I can hope to gain if I wade into it
compared to what I get using more commonly used namespaces?

System.ComponentModel is not very widely used for this.

Castle, Spring.NET og MS Unity are much more widely
used for these types of things.

If you are on .NET 4.0, then MEF does also provide some
similar capabilities, but with a more narrow focus.

I would suggest that you look at Castle if you need
this type of stuff.

Do not try and create your own. This is complex stuff.

Arne

 

[James A. Fortune]

System.ComponentModel is not very widely used for this.

Castle, Spring.NET og MS Unity are much more widely
used for these types of things.

If you are on .NET 4.0, then MEF does also provide some
similar capabilities, but with a more narrow focus.

I would suggest that you look at Castle if you need
this type of stuff.

Do not try and create your own. This is complex stuff.

Arne

Thanks for the tip Arne. If it's complex for you, then I am well
warned!

I'm almost through reading:

WPF Programmer's Reference
Windows Presentation Foundation with C# 2010 and .NET 4
Wiley, 2010
Rod Stephens
ISBN 978-0-470-47722-9

The first - and probably only - reference in the book to WPF using
what I might consider to be true dynamic loading is for dynamically
loading (XAML) skins. E.g., (p. 300):
....
// Load the controls
FrameworkElement element =
(FrameworkElement)Application.LoadComponent(
new Uri(skin_file, UriKind.Relative));
this.Content = element;
....

Note (p.283, ibid.):

"Some developers use the terms 'theme' and 'skin' interchangeably, but
I make the distinction that a 'skin' applies to a single application
(or part of an application), and a 'theme' applies to more than one
application."

While examples in the book include things like styles, event handlers,
dynamic resources, property triggers, templates and dynamic data
binding, none of the examples except for the skins example seem to be
doing anything at all similar to the kind of dynamic loading under
discussion. So I will take the good advice given by you and Peter
and try to keep up with C#'s newer and more likely relevant
capabilities - only venturing into older or more obscure paradigms
when forced by circumstance and the absence of newer methodologies.
I'll keep Castle and MEF in mind if such dynamic capabilities become
necessary or even desirable. My C# programming has to improve
significantly before I feel confident in evaluating the trade-offs
posed by third-party software. However, please keep expounding the
'why' of favorite patterns and best practices since the reasoning is
often glossed over in books and tutorials. I read much of the C#
Programming Language Specification. Even it too, often sails right
past the history and motivation for many different programming
elements. I call it "The book of hints." Maybe good C# programmers
are expected to be able to read between the lines and figure it all
out from those hints. I try to do that, but it doesn't keep me from
appreciating a simple, thorough explanation now and then. You two,
especially, and others in this NG have done much to help me fill in
some of those blanks.

James A. Fortune
(e-mail address removed)

 

[Arne Vajhøj]

I'm almost through reading:

WPF Programmer's Reference
Windows Presentation Foundation with C# 2010 and .NET 4
Wiley, 2010
Rod Stephens
ISBN 978-0-470-47722-9

The first - and probably only - reference in the book to WPF using
what I might consider to be true dynamic loading is for dynamically
loading (XAML) skins. E.g., (p. 300):
...
// Load the controls
FrameworkElement element =
(FrameworkElement)Application.LoadComponent(
new Uri(skin_file, UriKind.Relative));
this.Content = element;
...

Note (p.283, ibid.):

"Some developers use the terms 'theme' and 'skin' interchangeably, but
I make the distinction that a 'skin' applies to a single application
(or part of an application), and a 'theme' applies to more than one
application."

While examples in the book include things like styles, event handlers,
dynamic resources, property triggers, templates and dynamic data
binding, none of the examples except for the skins example seem to be
doing anything at all similar to the kind of dynamic loading under
discussion.

All this is presentation layer. One of the common places to
do dynamic stuff is as glue between layers. There are no glue
in front of presentation layer (not counting prankster glue
on the keyboard).

Also note that at least some parts of the .NET framework
development team apparently did not seem to be that keep
on the SPI model. That in combination with the big fraction
of .NET developers coming from VB6 and ASP classic is in
my opinion the reason why DI and AOP techniques has
become less popular in the .NET world than in f.ex.
the Java world.

However, please keep expounding the
'why' of favorite patterns and best practices since the reasoning is
often glossed over in books and tutorials. I read much of the C#
Programming Language Specification. Even it too, often sails right
past the history and motivation for many different programming
elements. I call it "The book of hints." Maybe good C# programmers
are expected to be able to read between the lines and figure it all
out from those hints. I try to do that, but it doesn't keep me from
appreciating a simple, thorough explanation now and then.

That type of books are indeed rare.

But "Effective C" and "More Effective C#" books exist. If they
are like the ditto for C++ and Java, then they could be an option.

Note that I have not read the books. I am only basing my
suggestion on the title, which is a pretty thin argument.

Arne

 

[James A. Fortune]

On 15-01-2011 23:07, James A. Fortune wrote:

 >                               However,please keep expounding the


That type of books are indeed rare.

But "Effective C" and "More Effective C#" books exist. If they
are like the ditto for C++ and Java, then they could be an option.

Note that I have not read the books. I am only basing my
suggestion on the title, which is a pretty thin argument.

Arne

I have both of those books, but I have not read them yet. They're not
that large so I should be done reading them within a few weeks. Maybe
someday I'll be able to write that rare book . Hopefully, those
two books will lead to my asking some more questions in this NG.

James A. Fortune
(e-mail address removed)

 

[Arne Vajhøj]

All this is presentation layer. One of the common places to
do dynamic stuff is as glue between layers. There are no glue
in front of presentation layer (not counting prankster glue
on the keyboard).

Also note that at least some parts of the .NET framework
development team apparently did not seem to be that keep
on the SPI model. That in combination with the big fraction
of .NET developers coming from VB6 and ASP classic is in
my opinion the reason why DI and AOP techniques has
become less popular in the .NET world than in f.ex.
the Java world.


That type of books are indeed rare.

But "Effective C" and "More Effective C#" books exist. If they

Insert '#' in first title.

are like the ditto for C++ and Java, then they could be an option.

Note that I have not read the books. I am only basing my
suggestion on the title, which is a pretty thin argument.

Arne