class WikiService(object):
def __init__(self, data_access):
self.data_access = data_access
def get_article(self, article):
return self.data_access.retrieve_wiki_text(article)
def store_article(self, article):
self.data_access.store_wiki_text(article)
def html(self, text):
pass # return wiki text converted to HTML
def statistics(self, article):
hits = self.data_access.hits(article)
return (hits, hits /
len(self.data_access.edits(article)))

Here we have a WikiService similar to the one we used in our IoC example. In addition to having a statistics method, this version is able to retrieve wiki text from the database and format it into HTML. It can also store edited wiki articles in the database. In this example we aren't particularly concerned with the code that transforms wiki text to HTML and so we've omitted it.

from springpython.config import PythonConfig
from springpython.config import Object
class WikiProductionAppConfig(PythonConfig):
def __init__(self):
super(WikiProductionAppConfig, self).__init__()
@Object
def data_access(self):
return MysqlDataAccess()
@Object
def wiki_service(self):
return WikiService(self.data_access())

This should look familiar. It is the same IoC container definition we used in the previous chapter. The following block diagram shows the components of our application, with the Wiki's view layer calling into WikiService, which in turn calls data_access, finally reaching the database.

class WikiServiceWithCaching(object):
def __init__(self, data_access):
self.data_access = data_access
self.cache = {}
def get_article(self, article):
if article not in self.cache:
self.cache[article] =
self.data_access.retrieve_wiki_text(article)
return self.cache[article]
def store_article(self, article):
del self.cache[article]
self.data_access.store_wiki_text(article)
def html(self, text):
pass # return wiki text converted to HTML
def statistics(self, article):
hits = self.data_access.hits(article)
return (hits, hits /
len(self.data_access.edits(article)))

To handle multiple requests for the same article, WikiServiceWithCaching stores the wiki text in an internal dictionary called cache. This cache is then checked for the requested article before falling back to the database if the article is not in the cache. The cache is cleared whenever new edits are made.Finally the statistics don't have any caching at all.

To bring in our new caching wiki service, we just need to change the wiki_service declaration in our IoC container definition.

class WikiProductionAppConfig(PythonConfig):
def __init__(self):
super(WikiProductionAppConfig, self).__init__()
@Object
def data_access(self):
return MysqlDataAccess()
@Object
def wiki_service(self):
return WikiServiceWithCaching(self.data_access())

This idea is pretty simple and should lessen the load on our database server. However, by mixing caching with wiki services we have violated the Single Responsibility Principle (SRP): a class should have one (and only one), reason to change. Changes to one of these functions could break the other. It is also harder to isolate these functions for testing and, ultimately, makes the code harder to read and understand.

class WikiProductionAppConfig(PythonConfig):
def __init__(self):
super(WikiProductionAppConfig, self).__init__()
@Object
def data_access(self):
return MysqlDataAccess()
@Object
def wiki_service(self):
return CachedService(WikiService(self.data_access()))

Our architecture has changed slightly, with the Wiki view layer calling into our CachedService.

Now the SRP is obeyed as each class has only one responsibility. One class handles the caching by passing off all necessary WikiService calls to delegate. However, it isn't very practical. While CachedService (Code in Text) separates caching logic from WikiService, our usage of an adapter introduces some ugly constraints. The CachedService must have the same interface as the WikiService in order to handle its requests and we even had to code a passthrough for statistics. CachedService is also too specialized and wouldn't work for any generalized solution. Every time we add another method to WikiService, we have to change CachedService, giving us a tightly coupled pair of classes. Let's fix that now.

class WikiProductionAppConfig(PythonConfig):
def __init__(self):
super(WikiProductionAppConfig, self).__init__()
@Object
def data_access(self):
return MysqlDataAccess()
@Object
def wiki_service(self):
return ProxyFactoryObject(
target=WikiService(self.data_access()),
interceptors=CachingInterceptor())

By creating a proxy and wiring it with our aspect, we have dynamically woven the aspect into the code. In our situation, we have created an instance of Spring Python's ProxyFactoryObject to combine WikiService with CachingInterceptor.

By moving the Spring Python object wiki_service from WikiService to the ProxyFactoryObject, our call sequence now fl ows through our new interceptor, as shown in the following diagram.

Now, instead of having a specialized cache handler, we have a proxy that links to our generic caching aspect. Whenever the view layer submits a request to wiki_service, the calls get routed to CachingInterceptor.

The key difference between CachingInterceptor and the earlier CachedService is how Spring Python bundles up all the information of the original method call into the invocation argument and dispatches it to the invoke method of CachingInterceptor. This allows us to manage entering and exiting from any method on WikiService in one place. This behavior is known as advising the target.

In our example, CachingInterceptor checks if the target method name starts with get. If so, it checks the cache, using the target method's arguments as the key (in our case, the article name). If the arguments are not found in the cache, CachingInterceptor calls WikiService through invocation.proceed() as if we had called it directly. The results are stored in the cache, and then returned to the view layer. If the target method name starts with store, the cache entry is deleted followed by invocation.proceed().