Am Montag, den 15.12.2008, 12:20 -0800 schrieb j5:
[...]
> I am wondering what are the benefits of creating a parameter object over an
> array? First thing I can think of is the criteria object can filter the
> input and set proper defaults so I wont have to do that in the
> getBlogEntries() method?
Exactly, validation, filtering and guaranteeing completeness of the
parameters can be done in such an object. I'm sorry for not providing
any information on this yesterday, here we go:
http://www.refactoring.com/catalog/introduceParameterObject.html
[...]
> I am familiar with general caching but not a caching proxy. If I am
> wrapping the domain model inside the "CachingProxy" how would that work?
The definition of the Proxy DP: "One class controls the creation of and
access to objects in another class". You would wrap your
"RealBusinessObject" into a caching proxy. The caching proxy shares the
interface of "RealBusinessObject" but reimplements all of the public API
that should be cached. Say, you want to cache getAll():
> Perhaps I am not familiar with the concept of a Caching Proxy. In my
> mind the way I was going to implement caching would be add a basic
> cacheGet(), cacheSet() function calls within each method inside the
> domain model. Could you provide a simple class skeleton of a caching
> proxy that would work in this situation? Or perhaps a code blurb
> outling how the flow would work in this case?
class CachingProxy
{
public function __construct(RealBusinessObject $real, Cache $cache)
{
$this->_inner = $real;
$this->_cache = $cache;
}
public function getAll()
{
if (!($value = $this->_cache->get(__METHOD__))) {
$value = $this->_inner->getAll();
$this->_cache->store(__METHOD__, $value);
}
return $value;
}
}
So you would cache "per method", not per object (of course, __METHOD__
might not be unique enough but you know your stuff much better than I
do).
> As for whether or not to let the model know about the data source. Yes, I
> could pass the data source into the model through the constructor. I would
> then need to create an adapter for the different types of possible data
> stores I might use. My thoughts is that if I can encapsulate as much inside
> the model I would be able to evolve to that point eventually. I am not sure
> if I am ready to tackle that yet.
Then don't let the architecture astronauts scare you :) Just start with
a data source which is bound do your domain model and refactor if
needed.
> Also, are you suggesting I create a model for each blog entry? The way I am
> currently have it is that I have one $blogModel which returns arrays of
> entries. If I allow it to return objects, they would be very simple objects
> with get/set methods to read its internal array data. These blog entry
> objects would not contain any datasource information, caching or save()
> methods.
Than the array might be sufficient. On the other hand, it might be
problematic, as refactoring n templates from arrays to objects might be
hard (except if you are going to implement ArrayAccess in the future but
that's a typical legacy sympton).
> The individual entry model would have to passed back into the
> $blogModel->save($entry) to be updated. Or would this be bad practice?
If it is sufficient and you always have your blog model around, that's
alright. It looks a bit like a service layer
(http://martinfowler.com/eaaCatalog/serviceLayer.html) but that doesn't
matter at all.
cu, Lars
没有评论:
发表评论