Controller-View

Model View Controller (MVC) is a well known design pattern. I really like it but in my personal experience, the model layer has all the logic and the controller becames only in a translater between user request and the model operations itself. Personally I find it very clumsy and prefer to merge MC into C. Please don't misunderstand me, I just my experience, taking in count the kind of apps I usualy develop and the way I usualy code.

With all that being said, my personal design patter is Controller-View (CV). All the logic is in the controller (even the db queries) and all the HTML-CSS-Javascript pack is managed in the views.

If not using ajax (like in this project) I usually have one controller class, which manages one system entity (therefore, one uri segment). E.g: Batch class, manages the seed batches entities, access the batches db table and use the /batch/... uri family.

In a controller I typically have the basic CRUD operations, in functions, which will translate into uri segments (e.g.: /batch/insert )

Usual operations are:
Browse : listing records (it usually is in the default controller function, and could it be named main instead of browse)
Create: insert new records. This is a form which evaulates all the logical validations (no matter if that validations already are in the view. here the problem is that the same validation has to be mantained in two diferent code locations. i don't like that very much). The form, once data is inserted redirects the page to the view record (recently created) or to the browse page
Update: similar to the create, but this one does the update validation. Here again, we have the same class validations logic splitted into view (javascript) and controller (php)
Delete: logical deletion of a record (updates its status)
* Kill: physicall deletion of a record (deletes a record from db). This is usually allowed only to admin users.

I just exposed one of the weak points of web apps validations in general. Entity validations. In the next blog post I'll share how we will face that problem, avoiding to multiplicate by 4 the same logic (php insert validatins, javascript insert validations, php update validations, javascript update validations). If it is not clear, here is an example: entity name field is mandatory and it should have 50 characters max. So far I have to code that logic in the view (through javascript pre-form-submit validation, or leveraging on html tags and properties), and also in the controller because we cannot trust that the view hasn't been compromised (or it just has a development error). So that, and to not raise a db error I should recheck that in the controller just before building the sql query.