Lars Strojny-2 wrote:
>
>> 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.
>
>
> [...]
>> Questions:
>>
>> 1. The getTotalBlogEntries() and getBlogEntries() have many options in
>> terms
>> of the $criteria parameter. I am wondering if this would be considered
>> bad
>> practice? I was thinking I could create a bunch of functions that take
>> less
>> number of options and give the end developer less ability to "mess"
>> anything
>> up. I have it the way it is now to "KISS".
>
> 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
>
>
> [...]
>
> cu, Lars
> --
> Jabber: lars@strojny.net
> Weblog: http://usrportage.de
>
>
>
--
View this message in context: http://www.nabble.com/Example-Model-review-and-best-practices-feedback-request-tp21018528p21021176.html
Sent from the Zend MVC mailing list archive at Nabble.com.
没有评论:
发表评论