0

Funny question: In a MVC web application for a cinema, I have Model classes like Film and Showing. Also, I have DAO classes like FilmDAO and ShowingDAO to retrieve data from the DB...

My question is, should I create classes for things that are not real "entities", but just page elements? I mean classes like Carousel or Sidebar, and their correspondent DAOs.

I think it's really weird to have a SidebarDAO, however is alkso something that is retrieved from the DB from a Controller to be displayed on the page...

MikO
  • 18,243
  • 12
  • 77
  • 109
  • 1
    please read http://c2.com/cgi/wiki?DomainObject and stop refering to them as "models" – tereško Jun 12 '14 at 20:14
  • @tereško, then, in your opinion both `Film` and `Sidebar` are **Domain Objects** of my app, and as such, they should be handled in the same way? – MikO Jun 13 '14 at 09:44
  • 1
    Actually, `Sidebar` would be a [presentation object](http://martinfowler.com/eaaDev/PresentationModel.html) and used by views. Also , you might find this kinda useful: http://stackoverflow.com/a/16596704/727208 – tereško Jun 13 '14 at 12:00
  • Thanks @tereško. I've been reading some interesting answers of yours... Just one question: what you call *Representation Objects* are pretty much the same as the *ViewModel* classes that L-Three metions in his answer below, or the ones defined here, for example: http://fuelphp.com/docs/general/viewmodels.html, or they are not? – MikO Jun 13 '14 at 12:16
  • "ViewModel" is actually what replaces a "Controller" in a MVVM. It is a structure which you use, when you have no control over the Model's API or/and the View (usually a case when you are doing 3rd party system integration). FuelPHP's "viewmodels" are just another misrepresentation of [simple php templates](http://chadminick.com/articles/simple-php-template-engine.html#sthash.zH5mDou2.dpbs) ... you really shouldn't learn application architecture from Fuel. – tereško Jun 13 '14 at 13:25

1 Answers1

1

The models you are refering to like Film respresent the data that is used by the view. It's the M in MVC. In fact, I like to see them as view models, as you would probably want them to be optimized for a specific view. So each view would have its specific view model; in which you could reuse specific common models of course.

This has nothing to do with data entities, which are part of the backend and not the frontend. Data entities just represent the entities as they are stored in the database, and they are probably completely different than the view models.

In your case, Carousel is probably just a control that you use in one or more pages. This means that you can create a Carousel view model, that contains all information for the carousel in order to display everything correctly. The Carousel view model could be a property of the page view model, that is passed to the page. The controller is responsible for getting the data from the database in the form of data entities, map those data entities to page view model and Carousel view model, and pass these to the view.

If needed you can add extra abstraction layers so that there is a service, application and domain layer in between your controller and the data layer (onion architecture etc); but this all depends on your requirements and environment.

L-Four
  • 13,345
  • 9
  • 65
  • 109
  • Thnaks, it's interesting the concept of *ViewModel* classes, I had never heard it before... – MikO Jun 13 '14 at 12:18