[wiki] Updated: IocContainerInternals/TheBasics/CommonPatterns

[email protected]
Newsgroups gmane.comp.java.jicarilla.cvs
Message-ID <[email protected]>
   Date: 2004-03-16T18:38:10
   Editor: 130.89.169.128 <>
   Wiki: JicarillaWiki
   Page: http://lsd.student.utwente.nl/jicarilla/IocContainerInternals_2fTheBasics_2fCommonPatterns

   halfway

Change Log:

------------------------------------------------------------------------------
@@ -117,9 +117,11 @@
 
 Other containers support a few types of caching. Their designers will take a good look at a particular set of problems, and will offer you only a few choices, that will work well for most solutions to those kinds of problems. Most frameworks designed for working inside a servlet engine are good examples. They'll offer a few types of caching, usually called "scopes". You can, for example, configure a component to be "shared" (between webapps), "singleton" (one component per webapp), or "per-session" (one per client session).
 
-A third choice, which is currently a lot less common (but one I like myself :-D) is to support every kind of caching. The only way to feasibly do that without getting a very ugly and cluttered codebase, is to encapsulate the caching choice into a truly seperate concern (which it really seems to be) and create an abstraction for it. Besides containers, resolvers, and factories, we'll need to have a "Cacher" of some kind. It probably needs to sit somewhere between the container and the factory. A typical setup might result in things like
+A third choice, which is currently a lot less common (but one I like myself :-D) is to support every kind of caching. The only way to feasibly do that without getting a very ugly and cluttered codebase, is to encapsulate the caching choice into a truly seperate concern (which it really seems to be) and create an abstraction for it. Besides containers, resolvers, and factories, we'll need to have a "Cacher" object of some kind. It probably needs to sit somewhere between the container and the factory. A typical setup might result in something like this:
 
-attachment:container_cache_sequence_diagram.gif
+           attachment:container_cache_sequence_diagram.gif
+
+Most containers today merge the whole caching concept with other concerns, so you won't typically see diagrams like this, nor will you easily recognize these abstractions in their code. I think that's a little ugly conceptually, but its working well for most of them in practice.
 
 == Concept merging ==
 


-------------------------------------------------------
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.