1

I'm trying to figure out the correct layout of classes, methods, files and folders for a MVC design based system.

Let say we have a Page. Page is a simple page with title, text and a sub menu. And it can also include a gallery (which would be a separate object both in the database and in the code).

  1. I would have a PageDAO class that would have all database related functions (it would extend main DAO class, that would hold generic DB functionality as select, save, delete etc)

  2. I would have separate Page class that would define variables and non-db related functions for this object

  3. I would have the MVC itself where PageModel would construct page DAO class and page class and build content that would then be processed in controller and prepared for a view

  4. Gallery would be defined in a separate class outside MVC (let say libs folder) and it would never be used as a view ( I mean, I would never call the gallery page itself). Page model would create Gallery class and controller would place it in a page view

  5. Menu class/function would be more generic function (as it would work for both pages and categories, if the code is used for e.g. shopping site) and would also be defined in a separate area (could be libs folder again). Menu setup based in that functionality would be called in model

The above means I would have the following structure

  • model, view, controller files and folders based on standard MVC approach

  • dao lib folder for all DAO classes

  • lib folder for classes like Page, Menu, Gallery

Does it look fair to you? I'm just anxious not to spread out the code over too much classes as it then means more 'includes' and more object calls. But perhaps that's the way to go? So far I haven't been using much MVC approach and been keeping files rather compacted. Want to get to know about the best practices

tereško
  • 58,060
  • 25
  • 98
  • 150
vault-boy
  • 523
  • 1
  • 6
  • 18
  • I don't see a general problem with your approach. Nevertheless, I'd propose to concentrate on the OO decomposition structure of your approach. – SteAp Jul 22 '12 at 13:50

1 Answers1

1

Here are few things for you to think about:

  • Your Page class is a standard domain object, but the PageModel class is not really a model. Model is a layer in MVC. What you call 'PageModel' is actually a higher level objects withing model layer, which create the pulic-ish interface so that views and controllers can interact with model later, without exposing any domain business logic. I call such structures "services", but there should be a better term for it.

  • Controller should not "prepare data" for the view. View is not a dumb template ( or at least, it should not be ), it should be a fill-blown objects, which is responsible for presentation logic and can deal with multiple templates

  • It seems that you are borrowing some concepts from HMVC, you should read a bit about that MVC-inspired pattern.

  • The instances of DAO, Page' class and what you callPageModel' all belong to model layer.

  • Fragmentation of code is not a major performance issue, especially when you enable opcode cache via APC. But premature optimization is a serious issue. Instead you should focus on making your code easily understandable. You can optimize when it works.

tereško
  • 58,060
  • 25
  • 98
  • 150
  • It seems I have difficulties understanding the model as a 'layer'. Based on MVC code examples, model that I have in mind is represented by model class which controller and view interact with. So what is 'model layer' per se? How would a code representation of having DAO, Page class and PageModel in 'model layer' look like? – vault-boy Jul 22 '12 at 17:53
  • @vault-boy , maybe this [answer](http://stackoverflow.com/a/5864000/727208) helps. – tereško Jul 22 '12 at 18:18