Re: [aus-dotnet] System.ComponentModel - Passing information back to Parent Forms

[Alex Hoffman]

> [acquisition] ... Spring does this too ...
Formal "Environmental Acquisition" is somewhat different (and much more
esoteric) than an object acquiring differing behavior in a particular
container or "context".

While System.ComponentModel isn't a full formal implementation of
Acquisition, it wasn't intended as a dependency injection mechanism -
which is why a .NET component has a link to its container.

"Context" as a backdrop to the provision of aspects applied to 
components has been used on the Windows Platform since MTS was released 
in 1996.  That AOP implementation was largely concerned with supporting 
transactions, but later was enhanced to include the other services in 
COM+, as reflected in what is now Enterprise Services in .NET.  Context 
is integral to the "interception" architecture that continues to be used 
in .NET today (but which will be deprecated in Indigo - it includes its 
own "hook" architecture).
I mention this because using different contexts to alter behavior in 
different circumstances (as you describe) has been used quite widely on 
the Windows platform in the past.
> The nice thing is that you can still do IoC using Spring even if you 
don't use the ApplicationContextAware interface.

It's the thing I like about it too.  I'm mainly interested in IoC, and 
can completely forget about those bits of the Spring Framework that 
don't interest me.
What I'm not too sure about is whether Spring or another IoC framework 
will be widely taken up by the .NET community for now - I don't work 
with many organisations dealing with .NET that are concerned with 
complex domain modeling and how objects are wired together.  The 
emphasis is often just on consuming the FCL and extending it's 
infrastructure in the creation of a propriety reusable services framework.
Coming from Java, do you see any difference in the communities?

Alex Hoffman


Nick Lothian said the following:
> [snip]
>
> > Why it needs to do that is interesting - the .NET component model
> > supports "environmental acquisition".  (See
> > http://www.ccs.neu.edu/home/lorenz/papers/oopsla96/acquisition.pdf).
> >
> > Through that, a hierarchical group of "services" in inherited 
> > containers 
> > can obtain attributes and behavior based on the *context* they find 
> > themselves in, and the path they used to arrive there.  Few 
> > frameworks 
> > support it - the most widely known being the Python based ZOPE server.
> Spring does this too (at least in the Java version - I presume the .NET one
> is the same in this regard). By implementing the ApplicationContextAware
> interface
> (http://www.springframework.org/docs/api/org/springframework/context/Applica
> tionContextAware.html), you'll get the ApplicationContext passed to you when
> the application starts up. There are subclassed versions of that interface
> for web applications, portal applications and rich-client applications that
> provide information specific to those environments.
>
> I've used ApplicationContextAware in the past to - like you suggested -
> write components that act differently depending on their environment.
>
> The nice thing is that you can still do IoC using Spring even if you don't
> use the ApplicationContextAware interface.
>
> I think that this model (optionally implementing an interface to get
> environmental acquisition) is  better than the "implement IComponent to
> play" model. Being able to use it with third-party code that comes as POJOs
> (or PONOs) is very useful.
>
>
> > It's a bit like having non-invasive AOP by context.
> I'm not sure I'd go that far - why would you say that?
>
> I suppose you could intercept method calls going through the context class,
> but I don't really see how that lets you separate out your concerns any more
> than normal OO programming. There's no real support for weaving new
> behaviour into the classes either (except writing more code in your context
> class).
>
> Nick
>
> Nick
> _________________
> You are a part of the Australian "dotnet" mailing list.
> To unsubscribe send "unsubscribe dotnet" or to re-subscribe send "subscribe dotnet Your Name" in the body of the email to: imailsrv@xxxxxxxxxxx
> List managed by: http://www.stanski.com
_________________
You are a part of the Australian "dotnet" mailing list.
To unsubscribe send "unsubscribe dotnet" or to re-subscribe send "subscribe dotnet Your Name" in the body of the email to: imailsrv@xxxxxxxxxxx
List managed by: http://www.stanski.com