Getting started with software design using MVC, OO, and Design patterns

hinghoo

I am just getting started on a new project and need to use MVC, OO and design patterns.

Here's the idea: Imagine a page that displays a set of widgets. These widgets are (usually) charts that are based off of data contained in several separate tables in the database. I use a running example of page that reports on a student's performance.

High Level Requirements

a page that displays a set of (HTML only) widgets.
widget's data will be based off a database query.
the page can be used to view separate datasets containing similarly laid out data. For example, a single page will display widgets that report on various aspects of a single student's performance.
want to see another student's performance, pull up another page. Displaying different widgets for different students is not needed (though it may be nice to have later).
There may be many students, but data contained in the database is similarly laid out for all students.
the way a widget is displayed may be changed easily (say changing a widget from displaying as a pie chart to display as a bar chart).
widgets should be able to be created quickly.

Low Level Requirements

Currently data does not change so widgets will not need to automatically update themselves.
Widgets may represent a ratio of two things (eg. a ratio of failed tests to successful tests as a pie chart), a series of points, or sometimes a single numeric value.
Development of new widgets should be a breeze, existing code need not be modified.
Framework to be used: Zend Framework, based on MVC.

There are (minimally) three things to define a widget: the dataset to report on (in the example above, the student ID), the query that describes the metric being reported, and a render mode (barchart, timeseries etc).

Here is a pass at breaking down the responsibilities of each layer of the MVC:

View: Zend views are HTML templates with PHP injected. They will contain one of several types of widgets. Widgets are of various forms including: static JPEG images (loaded from a remote site ie: <img src="http://widgetssite.com?x=2&y=3"/>, JSON based javascript widgets, or charts of various kinds (piechart, bar chart etc.)

Controller: Creates the widgets, assigns them to the view afterwards. The set of widgets that is to be displayed on a page needs to be maintained somewhere. Since I can't think of a good way to do this in the view, I'll add this to the controllers responsibilities for now. If there's a better place for this please shout. The controller will also have to handle any other input parameters and passing them to the widget. For example, the data_set id which may be passed at the url line as http:/.../report/?student_id=42

Model: The model, in the Zend Framework, is responsible for pulling the data and as such will most likely contain a class for each widget for accessing the database.

Some points:

The model here, represents the data for a particular widget. So necessarily, it will need to know what the query is going to be, in order to pull together the tables necessary to fetch that data.
There's an additional processing step that will most likely be necessary before the widget can present the data. This is dependant upon which renderer will be used. Sometimes it may require forming a url out of the data returned. Other times, a JSON array. Other times perhaps creating some markup. This can go either in the model or the controller or the view. Unless anyone can think of a good reason to move it to the controller or view, it is probably best to let this live in the model and keep the view and controller thin.
Likewise, a widget will be made up of 3 things, its parameters, its data, and its renderer.

One big part of the question is: What's a good way to represent the widget in an Object Oriented design? I already asked this once, couldn't get an answer. Is there a design pattern that can be applied to the Widgets that makes the most sense for this project?

Here's a first pass at a rather simple class for the Widget:
```
        class Widget{ 
          //method called by the view 
          render() {//output the markup based on the widget Type and interleaved the processed data} 

  //methods called by the controller: 
  public function __construct() {//recieve arguments for widget type (query and renderer), call create()}  
  public function create() {//tell the widget to build the query, execute it, and filter the data} 
  public function process_data() {//transform into JSON, an html entity etc} 

  //methods called by the model: 
  public function build_query() {...}; 
  public function execute_query() {...}; 
  public function filter_data() {...}; 
} 
```
Looking at it, I can already see some problems.
1. For example, it is straightforward to pass the widget that was created in the controller to the View to render.
  
  But when it comes to implementing the model it seems not so straight forward. Table Gateway Pattern is simpler to implement than ORM. But since table gateway pattern has one class for each model/table it doesn't seem to fit the bill. I could create a model for a particular table, and then within that, instantiate any other models needed. But that doesn't seem so to fit the Table Gateway Pattern, but rather ORM pattern. Can Table Gateway Pattern be implemented with multiple tables? What alternatives are there? Does it make sense that the controller creates the widget and the widget creates the Model?
2. Another issue that arises is that this design does not enable ease of widget creation. ie. Say I wanted to create a PiechartWidget, how much code can be reused? Would it not make more sense to use some OO ideas such as an interface or abstract classes/methods and inheritance?
  
  Let's say I abstract the Widget class so only the shared methods are defined concretely, and the rest are declared as abstract methods. Revising the Widget class to make it abstract (second pass):
```
        abstract class Widget{

  private $_type;
  private $_renderer;

  //methods called by the controller:
  //receive arguments for widget type (query and renderer), 
  protected function __construct($type, $renderer) {
    $this->_type = $type;
    $this->_render = $renderer;
    $this->create();
   } 

  //tell the widget to build the query, execute it, and filter the data
  private function create() {
    $this->build_query();
    $this->execute_query();
    $this->filter_data();
  }

  //methods called by the model:
  abstract protected function build_query();

  protected function execute_query() {
    //common method
  }

  abstract protected function filter_data();

  //method called by controller to tranform data for view
  //transform into JSON, an html entity etc
  abstract protected function process_data();

  //method called by the view
  //output the markup based on the widget Type and interleave the processed data
  abstract protected function render(); 
}
```
  Is this a good design? How could it be improved?
  1. I assume writing a new widget will require at least some new code to build the query, and maybe filter the data, but it should be able to use preexisting code for almost all of the rest of its functionality, including the renderers that already exist.
  I am hoping anyone could provide at least some feedback on this design. Validate it?
  Tear it apart. Call me an idiot. That's fine too. I could use any forward traction.
  
  A few specific questions:
  
  Q1. What's the best way to implement the renderers, as part of the Widget class or as a separate class? 1a. If separate, how would it interact with the widget class(es)?
  
  Q2. How could I improve this design to simplify creation of new kinds of widgets?
  
  Q3. And lastly, I feel like I am missing something here with regards to data encapsulation. How does data encapsulation relate to the requirements and play out in this scenario?
  
  Q4. How best could it be harnessed this project?
  
  Thanks in advance.

johanafm

The widgets all operate on the same underlying object, a student. If the various widgets each use a small subset of the student data, and if they also frequently are displayed alone (i.e. just one widget on a page), or if some widgets that aren't frequently displayed rely on costly queries then it might make sense to let the widgets deal with mapping themselves. Moreover, if these widgets work on data from one table each, the TDG is a way to go. But, in this case, each widget would imply a query, which can generally be expected to reduce efficiency over pulling all or most data with one query.
If you frequently display all/most widgets, or they each need most of the student data set, I'd let a student class deal with data mapping. And even in the above case, you could go with this appraoch, but let the student class use lazy loading for infrequently used widgets depending on performance costly queries so you don't end up unnecessarily pulling performance costly data sets from the db. Until they are needed.

As such, I'd probably go with mapping student to db, with or without lazy loading, and let the widgets get their data from this object.

Table Data Gateway implies that you're operating on a table or subset thereof, just as the row data gateway implies working on a table row or subset thereof. In your case, you are most likely working with several tables; a single row from some (student table), several from others (student_takes_courses table and course table).
Since you seem to be dealing with only mapping one class to the database, you could encapsulate this in the student class. If you want to put in the extra work of decoupling the student class from the db schema, look into using a data mapper.

If you anticipate the need for displaying data for several students in the future, create a registry to hold the students, otherwise it can be a singleton.

I'm assuming that your widgets all work on two dimensional data sets. No matter what the data represents, the structure should be able to stay the same for all widgets. The difference just lies in the textual output for the axis' (considering a pie chart slice as an axis) labels. For this purpose, I would probably let each actual widget extend Widget, pass them the student at construction and let each widget get the data it needs from the student by using public getter methods. If you implement lazy loading, the student object will deal with pulling more data from the db if it isn't prefetched.

For the output, look into the decorator pattern. Instead of having a renderer as a widget member, you have a reference to the widget as a member of the decorator. Also, give the decorators the ability to create output for html, json and uri. I.e. three render methods, not one. Where "create output" means returning the data, not echoing it.