> Hi Kevin,
>
> Better name would be "Blog", or? It does not represent a single blog
> entry but the business logic for the whole blog.
You are right. This model would represent the business logic for the whole
blog. I will change the name of the model from BlogEntry to Blog.
> Another option for this scenario would be the "introduce parameter
> object" refactoring. The "correct" parameter object might be a criteria
> object.
Interesting, yes I could do this as well. Perhaps something like
$criteria = $blogModel->createNewCriteria();
$critiera->setPage(1);
$criteria->setLimit(10);
$criteria->setUserId(array(1,2,3,4,5);
etc..
and perhaps a method to handle an array of options say
$critieria->setCriteria($this->getRequest()->getQuery())?
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?
> 2. I would like to eventually implement a heavy caching strategy for all
> my
> models. Any advice on how to implement it following best practices would
> be
> much appreciated. Note that along with most of the models I am developing
> the BlogEntry model does alot of joins to build results.
> When using a factory to create new instances of the entry object, you
> might wrap your domain model into a caching proxy.
> To return object is a good idea, as well as keeping the data source out
> of business. But I wonder if it is necessary to have knowledge of the
> data source in the model at all. Why not leave this in the factory
> public function createModel()
> {
> return new CachingProxy(BlogEntry(new BlogEntryTable()));
> }
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?
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?
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.
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.
The individual entry model would have to passed back into the
$blogModel->save($entry) to be updated. Or would this be bad practice?
Kevin
--
View this message in context: http://www.nabble.com/Example-Model-review-and-best-practices-feedback-request-tp21018528p21021183.html
Sent from the Zend MVC mailing list archive at Nabble.com.
没有评论:
发表评论