[fw-mvc] Example Model review and best practices feedback request

Hey Everyone,

Over the past few weeks I have been following the threads about model design
in order to incorporate best practices while designing the models for a
fairly large ZF project I am working on.

I was hoping I could get some feedback on the design I have so far as well
get some advice on a few questions I have.

Below I am including the details surrounding my BlogEntry model. I do not
believe this model is at all complex so it should be easy to discuss what
parts of it I could further improve or issues to further consider.

I plan to take the knowledge I learn here to improve the other more complex
models I have.

Few things to note:
- I am going for a thin controller/fat model design
- Perhaps not the BlogEntry model but models I will base off the BlogEntry
model I plan to expose to a developer API and public feeds
(rest,xmlrpc,json,soap,rss,atom,etc).
- I plan to keep related forms within the model and use them for input
filtering/validation and will be pulled out when re-displaying forms in the
view
- Fetching entry data will incorporate joins from several tables (ie. User
table, Sites table)
- When it comes to the result return format I have been using simple arrays.

BlogEntry Database (mySQL) Fields

- entry_id - bigint(20) (primary key)
- user_id - bigint(20)
- user_ip - varchar(255)
- session_id - varchar(255)
- site_id - bigint(20)
- entry_title - varchar(255)
- entry_urlkey - varchar(255) (unique index)
- entry_description - varchar(255)
- entry_body - text
- entry_total_comments - int(10)
- entry_createtime - int(10) (unix timestamp)
- entry_lastmodifiedtime - int(10) (unix timestamp)
- entry_publishtime - int(10) (unix timestamp)
- entry_allow_comments - tinyint(1)
- entry_ispublished - tinyint(1)
- entry_isdeleted - tinyint(1)

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()) **

** For these methods $criteria can consist of the following keys in order to
filter the results. (page, limit, order_by are not used in
getTotalBlogEntries() obviously)
page - set current page (defaults to 1)
limit - sets limit for results (defaults to 10)
site_id - array of site ids to use to filter results by
user_id - array of user ids to use to filter results by
user_ip - array of user ips to use to filter results by
session_id - array of session ids to use to filter results by
published - (int) filter results by published status. 3 - include published
and unpublished entries, 2 - unpublished only, 1 - published only (default)
deleted - (int) filter results by deleted status. 2 - deleted only, 1 -
non-deleted only (default)
order_by - (str) how to order results. options = create_date-asc,
create_date-desc, lastmodified_date-asc, lastmodified-desc,
publish_date-asc, publish_date-desc (default)

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".

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.

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?

4. If I wanted to use Zend_Paginator to handle result pagination. How would
I go about implementing it for use outside of the model. I was thinking for
the output for getBlogEntries() (and similar methods for other models) could
return an array('paginator' => $paginator, 'rows' => $resultSet). Any
thoughts about that?

I appreciate any and all feedback..

Thanks
--
View this message in context: http://www.nabble.com/Example-Model-review-and-best-practices-feedback-request-tp21018528p21018528.html
Sent from the Zend MVC mailing list archive at Nabble.com.