Should Views access data from Models using DB column names?

[eluser]mhiggins[/eluser]
xwero: I was having the same thoughts, it didn't _feel_ right for the views to be aware of DB columns. But, with a careful naming system and plenty of aliases like rogierb suggested, I can see how the views can refer to the alias from the query and if the DB changes, just update the SQL and keep the aliases the same so as not to break the views. Also, database functions like count, sum, round, upper, lower, floor, ceiling can be aliased, which might make things a bit easier.

[eluser]TheFuzzy0ne[/eluser]
[quote author="wiredesignz" date="1243363867"]Obviously nobody has read wikipedia: http://en.wikipedia.org/wiki/Model-view-controller

The controller notifies the model of the user action, possibly resulting in a change in the model's state. (for example, the controller updates the user's shopping cart).

A view uses the model indirectly to generate an appropriate user interface (for example, the view lists the shopping cart's contents). The view gets its own data from the model. The model and controller have no direct knowledge of the view.

View renders the model into a form suitable for interaction, typically a user interface element. Multiple views can exist for a single model for different purposes.

Controller processes and responds to events (typically user actions) and may indirectly invoke changes on the model.

[/quote]

That's an interesting point you make, but rather than believe a single source, I like to take what I can from multiple sources and form my own opinion.

At the end of the day, it comes down to personal preference I guess. Also, let's not forget that CodeIgniter runs from inside of an object, so things work differently from procedural MVC. In my opinion, having calling models or libraries from within a view, makes it more controller-like. I tend to keep simple logic in my views, such as if, foreach, for and while constructs (and so on), and keep the heavy work in my controller. Again, this is my personal preference, because I feel that the view is for presentation only. If I wanted to redirect the user, I'd do this before the view was loaded, not from within the view after finding that there are no results.

Hopefully this makes sense. What I'm saying is that my controller check that the model has returned the data, or makes a database call, grabs some results, and then uses that to grab some more results. It doesn't seem logical to me doing all of that from within a view. The view should simply format the data passed to it. It shouldn't contain lots of logic for grabbing data, processing it, and re-using it for more model queries. Again, this is just my opinion, but it's subject to change.

[eluser]wiredesignz[/eluser]

Also, let’s not forget that CodeIgniter runs from inside of an object, so things work differently from procedural MVC. In my opinion, having calling models or libraries from within a view, makes it more controller-like.

Everyone is entitled to code their application as they see fit. But, I'm sure most of us do actually call libraries from within views, even the CI tutorials show this.

The MVC design pattern holds true for both procedural and object oriented programming, it's goal is a separation of concerns within the application. ie: the Controller processes input / output, it does not process data etc.

The reason CI controller is always shown managing data is that originally the Model class did not exist in CI so the controller was used do do it's job.

EDIT:
@Fuzzy, another opinion for you to view.
http://www.phpwact.org/pattern/model_view_controller

The controllers are typically responsible for calling methods on the model that change the state of the model ...

..In MVC, The controller is NOT a mediator between the view and the model. The controller does not sit in between the model and the view. Both the controller and the view have equal opportunity to access the model.

[eluser]TheFuzzy0ne[/eluser]
Thanks for the reply. You've certainly given me something to think about.

[eluser]Colin Williams[/eluser]

Obviously nobody has read wikipedia: http://en.wikipedia.org/wiki/Model-view-controller

Most people don't read anything.

... but I now wonder is it in fact correct (according to MVC separation ideals) for the view to require knowledge of DB column names

Look, any argument that ANY part of your application is oblivious to the structure of its resources is beyond bazaar. And I wouldn't even take it so far as equating object models to the databases that store the information of those objects/resources. Whether or not the object schema matches the database schema is irrelevant, and probably only occurs for more simple objects.

You make a cat application. The view knows a cat has $cat->ears, $cat->whiskers and a $cat->tail (it has to know, or else what good is it?), but only the model worries about storing/retrieving that data.

[eluser]mhiggins[/eluser]

...any argument that ANY part of your application is oblivious to the structure of its resources is beyond bazaar.

I am actively trying to avoid the view needing to be aware of the DB or data storage layer. For example, if I want to use memcached, different DB servers/schemas, a 3rd-party API etc I think the view should not be impacted, it should simply know that $cat->whiskers will contain the data and the model must make this happen transparently. So in this single instance, I am trying to make the view oblivious to the structure of the (DB) resource. Perhaps I am wrong, but this is hardly beyond bizarre.

You make a cat application. The view knows a cat has $cat->ears, $cat->whiskers and a $cat->tail (it has to know, or else what good is it?), but only the model worries about storing/retrieving that data.

Yes, I agree.

If I have a photo gallery application and the view displays photo caption, your model can pull the photo data from your local DB or through the Flickr API... your view should not care one way or the other, it will still just show $photo->caption.

[eluser]Colin Williams[/eluser]

it should simply know that $cat->whiskers will contain the data and the model must make this happen transparently

And I said, "...only the model worries about storing/retrieving that data." My point is that if the database has a "whiskers" field, it does not automatically make it evil to reference $cat->whiskers in the view.

If I have a photo gallery application and the view displays photo caption, your model can pull the photo data from your local DB or through the Flickr API… your view should not care one way or the other, it will still just show $photo->caption.

Great example. Better than my cat one.

[eluser]xwero[/eluser]
The way i was thinking was to make the names view centered which means for example in the html view of the content you get $blog_post->content and in the rss view it is named $blog_post->description.

You could have a scattered configuration in/called by the controller method that binds the view variables with the model variables, this means if a model variable changes it's possible it affects multiple controller methods. If you use the controller as a pass through the view files are going to be affected so you just move the problem.

Another solution is to make the model methods view aware but where is the limit? Do you stop with fetching the columns from the database the view needs or do you extract related data from other tables too if one view needs it but another doesn't? I think in the latter case the model takes on a controller responsibility.

I think you can't make a clean cut between the data and the view because in situations you manipulate the data you need to know the data origin and that will be made more difficult if you obscure it.
You could make a clean cut for fetch methods only but then there are view centered views and model centered views which means it will be harder to transform a view centered view to a model centered view and vice versa.

I go with model centered view as it is the least error-prone.