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?

Soybean

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

Chromoprotein

So it sounds like you guys are suggesting there should be a 1:1 model-to-controller relationship at least. Is that correct? – Soybean

That's correct. As a rule of thumb. There are some marginal situations where this won't apply but as a starting point it's just fine to obey it. – Chromoprotein

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

Equipoise

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.

Ormandy

Could you tell me a bit about what he suggests? While I appreciate your response, it's not immediately helpful beyond telling me where I can go to potentially find helpful material. – Soybean

Well, MF breaks the book up into narratives and patterns. The narratives are really what you want, because they put the patterns in context and explain when you would choose one alternative vs. another. The patterns themselves are pretty terse by themselves, but you can see them online: martinfowler.com/eaaCatalog The reason I suggest this book is because (1) it's absolutely basic knowledge, especially the web presentation patterns; (2) it's a very readable first patterns book; (3) every MVC framework is built using the PoEAA patterns (this goes back to (1)). Hope this helps – Ormandy

To take it back to your original question: the narratives in PoEAA discuss how to make "architectural" decisions like how to partition your code into separate classes. For instance, his book is very good on the Data Mapper vs. Active Record distinction, which is the choice between mapping one model class to each table in your database (AR) or having an extra layer of indirection (DM) to simplify your controllers. – Ormandy

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.

Dever

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?

Sitton

+1 Thanks for the suggestion, @tybro0103. It's been several months since asking this question, and I must say that I agree with you in that time will teach us what is necessary to know. I feel much better about structuring my projects than I did when I authored this question. Thanks for chiming in! – Soybean

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.

Gargantuan

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.

Stacey