In n-tier, distributed applications, we have to decide which logic deploy where. Those deployments are all about installing components in specific places but, what are components exactly? What distinguishes a component with respect of a mere class?
Actually, as classes do, components take ownership of cohesive responsability but components are logical units from a physical perspective. In MS .NET terms, components are redistributable assemblies (.dll) of one or more classes
But, wait, it's not so easy: new considerations arise in this context
- Security: When one part delivers a component to some other, how can the receiver be sure he/she's loading the original component (not tampered, not violated in any way). How can the sender be sure that calls to his/her component come from the receiver and not from someone else who got an illegal copy of the component? How can we protect, given a component, about illegal decompiling, illegal use of reflection on it and, most of all, illegal inheritance from one or more classes which, under the façade of the expected ancestor, expose a different behavior than expected?
- Versioning: how to deal with different versions of a component without breaking usage for legacy clients of such component? In the previous infrastructure, Windows DNA, such issue was known as DLL Hell
- Configuration: where must be put, in the Setting.settings project file or in the app.config file? What if the solution has several project-components? Where the component config info has to go in such scenario?
In this eighth webcast, Dr. Joe Hummel focuses on the design and creation of .NET components. He explains what component references are and how the .NET CLR deals with them via component metadata
With respect of security issues, Hummel offers some notions on Threat Modeling and how to avoid it via strong-named assemblies
About versioning, know the benefits of the .NET's Global Assembly Cache and how it says bye-bye to the Windows Registry (leaving behind the DLL Hell)
Finally some notions of pluggable components or, said in other words, what role play in .NET the elements configuration, configSections, sectionGroup and section? What role plays the applicationSettings element? Tired of being tired of never finishing to understand it?
So come on, join us again and let's watch together a new chapter of Dr Hummel's series "Architecting Smart Client applications"