[wiki] Updated: IocContainerInternals/TheBasics/CommonPatterns

   Date: 2004-03-16T19:09:18
   Editor: 130.89.169.128 <>
   Wiki: JicarillaWiki
   Page: http://lsd.student.utwente.nl/jicarilla/IocContainerInternals_2fTheBasics_2fCommonPatterns

   first version

Change Log:

------------------------------------------------------------------------------
@@ -1,4 +1,6 @@
 [wiki:IocContainerInternals Contents] | [wiki:IocContainerInternals/TheBasics/TheSmartHashMap Previous] | [wiki:IocContainerInternals/AdvancedStuff/ScriptingAndXmlConfigurationFiles Next]
+----
+''TODO'': this page is not exactly in easy english, nor is it easy enough to read in one go. And where'd the simpson samples go?
 
 = Common Patterns =
 
@@ -125,25 +127,37 @@
 
 == Concept merging ==
 
-''TODO''
- * union of factory & container (spring is good example)
- * union of container with embeddor (merlin+repository is good example)
- * union of unnamed features and plumbing with the container (ie classloading, metadata)
- * union of protocol handling with the container (ie servlets)
+We've now identified several key concepts, even writing up basic interfaces for them. It should come as no surprise to you that most of these interfaces are not actually in use in actual containers. Besides being naive, these interfaces are also rather "small". Most containers merge a few concepts. Let's look at some common choices...
+
+=== Merge factory and container ===
+
+If you only decide to support a single type of component (for example, only javabeans) and just one or two types of caching (for example, only "singleton" and "per-request"), you can do away with distinct factory objects and distinct caching helpers. The container just handles instantiation and caching directly, probably using some static or private utility methods.
+
+This usually results in a system that's less adaptable to changing circumstances using composition. Instead, you're likely to see class size increase over time, and you'll see a (sometimes complex) class hierarchy of container implementations as new features are added. For example, you might add support for pooling components by overriding a method or two in a subclass.
+
+=== Merge container with embeddor ===
+
+In the examples so far, we've made it appear as if the user would actually be calling methods on the container. With quite a few containers, things don't work that way. The container is locked down quite a bit. Instead of the container user being responsible for the assembly, the container user '''declares''' what it is that he wants assembled, usually in one or more xml configuration file. The container will read the config files and from there call the assembly methods on itself.
+
+This results in a system that has a much more rigid seperation between the container and the container-using code. The container is given much more control. This hides a lot of complexity from the container user (you don't need to any "embedding", you just write a config file and start a program) and reduces the likelyhood of misconfiguration. The main disadvantage of a system like this is that its often more difficult to unit test, and more difficult to develop.
+
+=== Merge other kinds of system services with the container ===
+
+I haven't talked about things like classloading, jar management, classpath management, configuration management, logging, instrumentation, or transaction support. None of these things have much to do with the "core concept" of inversion of control. Yet there are several inversion of control solutions out there that come with a lot of support for these things. If the container is also the "embeddor", and in strong control of the environment, use of some of these features may be mandatory (for example, you'll be required to provide your application to the container in some kind of archive format).
+
+=== Merge program flow pattern with the container ===
+
+Some IoC containers are built with a specific type of application in mind, and they enforce a certain application structure for those applications. For example, the container may handle request/response logic for its components, and it will enforce a contract on the components to fit into a piece of the request/response program flow. The servlet api is probably the best example of this kind of control. Various other web application solutions, often built on top of the servlet api, do similar things. Struts is an example of a container optimized for a certain kind of application. It enforces a particular kind of the Model-View-Controller architecture.
+
+With these containers, their support for this kind of application flow is often mentioned as their dominant characteristic. The fact that they are actually also an IoC container will be somewhat hidden. A lot of the confusion in switching IoC containers is when people expect containers to enable the application flow they're used to.
 
 == Facades, frontends and helpers ==
 
-''TODO''
- * providing simpler interface
- * isolate assembler from complexities
- * purposefully limit choice
- * model frontend like
-   * an assembler (merlin)
-   * builder (pico)
-   * manager+config (fortress)
-   * embeddor (phoenix)
+Another common pattern that's a little different from concept merging is that of concept hiding. A container may internally have a really granularly componentized setup, but hide this from the user in the form of a simple, single '''facade'''. This means the average user does not need to be aware of all the concepts introduced (lookup mechanisms, factories, caching policies, ...), but instead focusses on getting the assembly done. The disadvantages of using facades is that they'll usually will make some complex setups difficult. The best facades provide a way to "look behind the curtain".
+
+Frontends are known by different names, and their setups are often a little different. The term "facade" is not actually in use in containers as far as I know. Instead, there will be a {{{Manager}}}, {{{Builder}}}, {{{Embeddor}}} or {{{Assembler}}}. Some containers use, descriptively, {{{Frontend}}} :-D. The role of these different facades is usually much the same.
 
- ...is all much the same
+When trying to figure out how a container works, I usually recommend that people look at what the front end does, and try to do that themselves "manually" by interacting with the things behind the curtain in code they write themselves. This is because the call stack and behaviour of these frontends often seems to be a large part of what makes containers complex, especially if the containers provide lots of features that go above and beyond "basic IoC".
 
 ----
 [wiki:IocContainerInternals Contents] | [wiki:IocContainerInternals/TheBasics/TheSmartHashMap Previous] | [wiki:IocContainerInternals/AdvancedStuff/ScriptingAndXmlConfigurationFiles Next]


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click