Hello all,
I went through the entire MVC sticky thread and came up with a few questions. Several responses in the thread posted similar questions, but there were not clear answers.
- There was some discussion about some pages not needing authentication and yet one of the filters in the filter chain handles authentication. How do we tell this filter not to processRequest()? There wasn’t a clear solution presented for this problem. Do we rebuild the chain every time the FrontController runs? If so, we would have to examine the request to determine what page we are on before filtering. This seems to break the architecture. Some also argued that authentication shouldn’t take place in a filter.
- What is the best practice for storing the logged in user? I would assume a variable $loggedInUser. However, some questions come up:
[LIST=2] - Where is the variable stored? In the FrontController (if using one)? In the auth filter mentioned above? As a global? Somewhere else?
- Is this variable a reference to a User Model? Or a reference to a lighter weight User class, that just has id, username, admin_state?
[/LIST]
- I’m not sure I completely grasp the idea of the filters. I think I get the idea of the authentication filter, but what else would be implemented as a filter? They mention using filters for pre- and post-processing steps. What exactly do they mean there? Validating $_GET, $_POST and $_REQUEST parameters? Could someone please provide some clarity?
- What are the best practices for Model design? Should the interface to a Model just contain the basic CRUD methods? CakePhp, for example, puts the CRUD methods in the Model’s corresponding Controller. But when examining the description of MVC, to me it seems that they belong in the Model. In the Wikipedia article for MVC they state the following: “The controller receives input and initiates a response by making calls on model objects.”
When I read that, I visualize the following example:
User clicks the delete link for a product on a web page.
The controller receives this request and executes it like so:
$model = Models::getModel(‘product’);
$model->delete($id);
But in CakePHP it would be:
productController->delete($id);
Perhaps CakePHP uses a slightly modified implementation of the MVC pattern??
And now my database interface questions.
Again I’m searching for best practices. I’m in the initial phases of coming up with a design for a database interface design and have come up with the following interface:
interface MyDatabaseInterface{
function addItem($new_item);
function getItem(id);
function deleteItem(id);
function updateItem($updated_item);
}
Ok, fine and dandy. A concrete implementation of this may be a MySQL implementation that knows how to create MySQL queries and perform the above actions. However, the above interface is a bit limited. Say I wanted to delete all items where name=“Fred” (or search for items where name = fred). I could add an interface methods called:
function deleteItem($conditional);
function getItem($conditional);
The MySQL implementation would construct a query like "DELETE (or SELECT) from table WHERE name like ‘%fred%’;
Fine and dandy. But how should the “$conditional” parameter be designed. I once saw a solution to a similar problem, where they passed in a “Where” clause as a parameter.
So the function would be:
function deleteItem($whereClause);
The $whereClause may make sense for MySQL or SQL, but not for other databases. If I used that in my database interface above, I would be tying specifics of MySQL to the database interface, which should be agnostic of all concrete implementations.
So, what is the recommended way for designing such interfaces?
Thank you for reading and I look forward to reading your thoughts on the above.
