Am Montag, den 15.12.2008, 09:56 -0800 schrieb j5:
[...]
> BlogEntry Model Design
>
> - Internally uses a TDG for create/save/delete functionality
> - Internally uses an Select object() from TDG for select queries.
>
> public function create($data=array())
> public function save($data=array())
> public function delete($entry_id)
>
> public function getById($entry_id)
> public function getByUrlKey($entry_urlkey)
> public function urlKeyExists($entry_urlkey)
>
> public function getTotalBlogEntries($criteria=array()) **
> public function getBlogEntries($criteria=array()) **
Better name would be "Blog", or? It does not represent a single blog
entry but the business logic for the whole 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.
> 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.
> 3. As I mentioned earlier, my models output simple array structures based on
> the joined database table fields. In the view I am relying on these fields
> not to change. I am thinking I might alter the return format to be objects
> that simply encapsulate the arrays and provide simple accessors/setters for
> each entry so I can insulate the views from any future database changes.
> Originally I wanted to stay away from doing this as I felt it adds alot of
> overhead to the application and make caching alot easier but I am realizing
> it would be a better idea in terms of maintability. BTW I am aware I could
> use the TDG to return row objects but I want to keep the datasource
> implementation internal in order to future proof external code. Any thoughts
> based on my current design?
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()));
}
[...]
cu, Lars
--
Jabber: lars@strojny.net
Weblog: http://usrportage.de
没有评论:
发表评论