Proper Design of a MVC Project [closed]

Question

I've been using Kohana for a couple months now, and am still relatively new to the MVC style of organizing your code/presentation/db-layer. Unfortunately, while there is plenty of documentation on how to create a controller, establish a view, and interact with a db via a model, I've not found many resources that deal with clean, and suggested development patterns.

Let me give a quick example:

My latest project has one controller, because I'm not sure if I should be making many more than that...or when I should make a new one. How exactly do I determine when a new controller is needed, along with when a new model is needed?

Answer 1

I'd suggest you to have a look at the resource oriented architecture, first. This won't give you any direct guidelines of how to organize your code. However, when thinking in terms of resources life is more easy when it comes to deciding whether or not to create a new controller. Once you manage to identify a resource in your system, it's usually a good thing to create a model plus a controller for it - although, this is just a rule of thumb.

Some additional points:

• look for resources and create a model and a controller for each of them (rule of thumb)
• don't be afraid to create models for resources that don't persist
• think about controllers as "plumbing" or "wiring" of user to the business domain - their role is to handle user requests and forward the answer back to them - keep them as thin as possible

Answer 2

The rule thumb is as follows: when I identify a new kind of "item" that my app. needs to manage, I ask my self these questions:

(1) Should items of these kind be persistent?

(2) Are there going to be many instances of this item?

If the answer to both questions is positive I conclude that the said item should be a model (or model-element or domain-class, depending on the terminology of your MVC framework). When I define a new model element I also define a controller for it that will support the four basic operations: create, retrieve, update, delete (it likely that your framework can generate a default controller for you).

Answer 3

You might want to get a copy of Martin Fowler's 'Patterns of Enterprise Application Architecture.' The Web Presentation section talks extensively about how to structure your code when using a Front Controller-driven framework, like any of the current wave of MVC frameworks.

Answer 4

I like small controllers with a clearly defined function or set of functions. This usually means one controller per page (or set of similar pages). In my Kohana site, CSSMySite I have about, blog, contact, css and post controllers.

All the about controller does is set the template. The blog controller interacts with the blog model to list multiple posts from the database. The post controller interacts with the blog model to display one post from the database.

Any time I have data that is persistent (blog posts) or used multiple times (list of states for a dropdown box), it goes into the model. Models can be accessed by different controllers so it does not have to be a one-to-one mapping of model to controller.

Answer 5

Perhaps a good way to learn good MVC programming is to spend some time in Ruby-on-Rails. I started using rails a while back, and as an indirect result I believe I have a very good understanding of MVC now. I view rails as the epitome of MVC. At the least, it could be a fun way learning MVC... what do ya'll think?

Answer 6

Here is an example of what I have been doing in my Kohana app.

I needed a 'latest news' section, so I set up a controller, model and view titled 'news'.

My news controller had methods index(), feed() and media_releases().

My model consisted of db queries which get my news data from a MySQL database.

And my view is just a lot of HTML with some <?php echo $title; ?> and the like.

Answer 7

Is there a reason why you can't define a generic systems that works globally levaraging database metadata? It seems to me generally writing any code at all to access and display simple data is an unecessary redundancy.