I am working on a project with zend framework and i need your advise on the right way to fetch data from the database.
Am making use of Zend_Layout to load my template. The appropriate view is then loaded into the template.
On the template, there is supposed to be a section that displays data from the database (e.g Categories). Since i am using one template, the data will be displayed on every page requested irrespective of the controller or action called.
I know its not a good practise to fetch the data from the template and it wouldn't be a good idea to fetch the data from each action executed. I dont know if the right thing to do is to use helpers to fetch the data from the database, but wouldn't that go against the whole idea of MVC.
You haven't mentioned the option of using a Model class to fetch the data. That's the "M" in MVC. :-)
A Model class is one that has an interface the View can use to request specific fragments of data. Inside the Model class, it may use a mix of using Zend_Db_Table methods, and also custom SQL queries (executed directly through Zend_Db_Adapter's query() method). Whatever works to get the data.
The point is that a Model encapsulates all the logic needed to supply data in a format the View can use.
See also
"An Introduction to Domain-Driven Design" at Microsoft.
"Domain-Driven Design" by Eric Evans.
Related
I am creating an MVC inspired PHP framework, mainly for learning purposes.
I basically have the framework created and am building an app on it and improving the framework as i go along.
I am still confused/not sure about certain aspects of this sort of architecture, and at the moment i am questioning my implementation of the View part.
How i have set up my framework:
Its a very simple set up, for example: you go to the url /post/post_id, this will load index.php which will instantiate the router. The router will then check the url and instantiate the correct controller and method based on the url. In this case it would be PostController, and the method would be a default method that would use the post_id to get the posts data from the relevant model. Next the controller would set up a "data" variable that will hold the data to pass on to the View, and this is where i am confused - should it send to its own View object (a view class file dedicated to the PostController), or to a generally used View class that is used by all controllers to load an html file?
At the moment my controller is sending data to the View class, this data includes what template file should be included/shown, and the actual data for the page (what we got from the Model through the controller).
My question is this:
Should this type of system have one View object that renders all of the views (html files) based on what data is given to the "render" method, or, should each controller that eventually sends data to the View have its own View object/class?
Meaning, should PostController send a request to the general view class, the same one that is used by all controllers to renders pages, or should the PostController send to a dedicated View Class (call it PostView if it makes it clearer), and this class will then render the specific html file?
Basically if it should be one View class for all controllers that will render what ever html file the controller tells it to, or if there should be many View classes, one for each page load.
NOTE:
I know a lot of questions have already been asked about MVC in PHP, but i could not find an answer to my question in any of the answers.
A bit about MVC:
In the original MVC pattern (presented by Trygve Reenskaug in 1979), the controller updates the model, the model notifies the view about the changes, and the view pulls its data from it. Though the pattern was thought for desktop applications - each M-V-C "triad" beeing related to a single control in a window (a button, a textbox, a checkbox, etc). So, each control on the screen had an MVC "attached" to it.
Since, in web applications, the model-to-view notification step is not (or can not be) present, the original pattern can not be applied as is to them.
But a most similar approach can still be relatively easily implemented: the controller updates the model, the view pulls data from it (irrespective of the controller). I think it's called "Web MVC Model 2".
There is a multitude of web MVC variations. You are using one in which the controller takes the role of an intermediary between the model and the view.
So the controller is the only one component communicating with the model.
The view's responsibility:
The responsibility of the view component is the presentation logic - which should not be assumed by the controller at all. Beside loading and rendering template files, this kind of logic involves the preparation of the data fetched from the model for displaying purposes. The result of the preparation should, preferably, be a list of values of primitive types (strings, booleans, integers, arrays, etc) which can be easily "injected" into the template files during the load-and-render process.
Examples of presentation logic:
Example #1: If you would fetch the value 123.45 (from the column amount of a table revenues) from the model, the presentation logic would consist of formatting it to the string 123.45 USD, in order to be displayed in a template file.
Example #2: Formatting a fetched date value of 28/05/2019 to 2019-05-28 by using a code snippet like this:
$fetchedDateFromModel = '28/05/2019';
$time = strtotime($fetchedDateFromModel);
$formattedDate = date('Y-m-d', $time);
The value of $formattedDate would then be "injected" into a template file.
Example #3: Setting a boolean value based on some model data, in order to be used in a template file for deciding if a button ("Get Bonus") should be active or not.
$paidAmount = 512.79; /* model data */
$isActiveGetBonusButton = false;
if ($paidAmount > 500) {
$isActiveGetBonusButton = true;
}
The answer (in respect of your chosen MVC approach):
By using a View instance in all controllers, you would be forced to perform specific presentation logic in each controller - before passing its result (e.g. the list of the prepared values) to the used View instance, in order to further just be "injected" in a specific template file.
Whereas, if you are implementing a dedicated view class (like PostView - which, preferably, inherit a base class View containing the render() method) for a controller class (like PostController) - so a 1:1 relationship, but see it as a loose one! - you can pass the data fetched from the model, in an unprepared form, from the controller to the view. The view class would then correctly take the responsibility of preparing the data for displaying prior to actually load and render a specific template file. E.g. of performing the whole specific presentation logic.
Note: In "Web MVC Model 2" - where, ideally, the controller has no knowledge of the view component - the above argument is more obvious:
the PostController just updates the model (when an update step is required);
the PostView fetches data from model, prepares it for display, and displays it (by loading & rendering a template file like posts.html.twig, for example). In other words, the view component performs the whole presentation logic by itself.
The best way, IMO, is to have this View or Template class do all the work related to views with just one simple method: render(string $templateName, array $context = []).
This allows for easy extension or creation of adapters. You should make your controllers use this method. If you use a DI Container in your framework, you could do a TemplatingAwareInterface and implement that with a trait that allows setter injection. That will inject the templating service on fetching from the service container. That way, you can use $this->templating->render() in your controller, without having to either make it global, nor constructing the templating service inside the controller, nor injecting the container into the controller.
Having one view class for each type of controller is cumbersome, harder to maintain and I don't really see a reason for it.
I've only just started learning CodeIgniter, so please excuse any misunderstandings I have.
I understand that the controller calls models and views. Views contain the HTML, models contain the database functionality etc.
I don't want to have to write code out to create a header menu, footer menu, side menu etc, in each of the controllers that import the menu structure into the view, so after some googling, it would look like it would be best to write a library in which my controllers can call to retrieve the type of menu they want.
My question is:
Would I place my database queries for retrieving the data to build each menu in the library itself, or would I delegate it to a model and call the model from the library? For the menu construction, I don't need to write to the database, just read the data it contains.
Many thanks
I never put any query directly in the library, as I believe that goes against the MVC that CodeIgniter intended.
I would aim to always make functions for simple database queries in the model, so that you may re-use them in various other portions. This allows you to return the data from what you need via the database when you require it. Which in turn allows you, in the library, to add additional caching or manipulate the data as it comes from the model.
I based that from 3 years of working in CI, and this little picture on this page: http://ellislab.com/codeigniter/user-guide/overview/appflow.html
Using PHP 5.x
Question, lets say I want to display results from a database. Lets say the last 30 stories from the database. Using OOP and MVC would the ideal setup be you have a class that connects to the db, a class that queries the database to get the information then a class that handles the display of the results and then a page that puts it all together?
So basically I would pass the db connection object to the class that gets me the story results from the database Then pass the story class object to the display class to build the view then pass that back to the view itself and echo out the value? Hopefully this makes sense, just trying to see if Im understanding this:
dbconnect_class.php
storyresults_class.php
storydisplay_class.php
Include all 3 into a page such as display_stories.php, which I believe is the controller in mvc, then run the code and display it in the view which would be in its basic form an include to a template file.
MVC meaning Model -> View -> Controller. In most of the frameworks the request comes to the Controller, the Controller asks the Model to retrieve the database results then the same Controller sends the results to the view in order to display them so that's the basic breakdown of a MVC application.
Don't pass the results object around. That will mean the display class needs to know the implementation within that class.
What you can do is let the controller get the results then pass the results to the display class.
You can make a data class that keeps the data in a suitable object which you can then pass to the display class.
However, this is just some general oop advice but for better mvc, you need to read on that. Some links have been provided by others.
Unless your using a template engine it would be very difficult to not write php code in a view file. At the company I work for, we have developed a set of UI components that allow us to bind data to a component in the controller and have that component render on the view, similary to how asp.net controls work.
I’m trying to learn and fully understand mvc pattern and learn php at the same time. I decided to built basic mvc framework that I could use on various projects later on. Having read lots of posts in here regarding mvc and coupling between models/views/controllers I’m a bit lost.. At the moment my understanding is that in web application controllers deal with coming request from browser and, if necessary, calls methods on model classes telling models to change its state. Then controller instantiate appropriate view class that will be responsible for displaying interface.
Here's the bit I don’t understand...
Now should controller pass appropriate model object to view and view should pull out all the data from model when needed?
Or controller should grab data from model and pass it to view, possibly wrapping it all into single wrapper object that view will access and grab data from there?
Or view should simply instantiate appropriate model when needed and pull out data directly from model object?
From what I read here
http://www.phpwact.org/pattern/model_view_controller
I’d lean towards the 3rd option where controller doesn’t pass anything to view and view instantiates model it needs. This is because:
view and controller should have same access to model
controller shouldn’t act simply as mediator in between view and model.
Is there really one correct way to do it or it rather depends on project? Also what approach would you recommend to someone who has decent understanding of OOP but is relatively new to php and not too clear on mvc architecture. Or maybe I should go with whatever seems right to me and learn from my mistakes (would like to avoid this one though ;)?
Now, please let me know if my question is not clear will try to better explain then.. Also I read lots of posts on stackoverflow and numerous articles on different sites, but still would appreciate help so thanks in advance for all answers.
Personally, I've always been a proponent of #2. The view shouldn't care about the model. The view shouldn't have any processing at all for that matter. It should do what it's supposed to do, format data.
The basic flow of control should be thus: The controller recieves a request from a browser. It processes the request, decides what data is needed, and retrieves it from the model/s. It then passes the data into the view which format the data and displays it.
As an extension, user input is processed inside the controller, and saved into a model if needed, then feedback is fed into a view, etc. The key point to take away is that processing happens inside the controller.
Personally, I've always been a proponent of #3. The view shouldn't care about the controller. The view shouldn't have any dependency on the controller for that matter. It should do what it's supposed to do, show a view of the model.
The basic flow of control should be thus: The controller receives a request from a browser. It makes any updates to the model, that is relevant, and then selects a view. The control is then passed to the view, which gets data from the model and renders it.
As an extension, user input can be consider part of the model, and both the controller and the view may read from it. The key point to take away is that Controller and View should have no dependency on each other. That's why the pattern is called MVC.
Now, personally, I find MVC a bit too tedious, and so I usually conflate Controller and View more than this. But then that isn't really MVC.
Web MVC and Desktop MVC are two very different beasts.
In Web MVC, a link in a View calls a method on a Controller, which updates a Model, and then redirects to an appropiate View, which opens up a Model and shows what it needs.
In a Desktop MVC, option 3 is wrong because both the view and the model should use the same reference. In Web, there's no choice.
Option number 2 is not MVC. It's MVP, wherein the Presenter is a mediator.
A Controller has Write-Access to a Model; a View has only Read access.
This is a very interesting question.
From my experience most implementations in php assign a model variable to the view:
$this->view->my_property = $modelObj->property
This is common practice.
The common reasoning for this is that if you send the object then you can call methods that modify the object from the view.
//in the controller file
$this->view->myObject = $modelObj;
//in the view file, you could call an object modifying method
$this->myObject->delete();
And modifying the model from the view is considered bad practice. Some people thing that they don't want their designers being able to call model modifying methods from the view.
That being said. I don't agree with the common practice and tend to assign the whole object to the view and display it from there. And just discipline my self to not make operations there.
And a third option is to assign the whole object to the view. but some how in the objects disable methods when they are called from the view.
I think this is just a generic argue about what is better "push" or "pull" model. There is no "absolutely" best solution.
I had a very similar question earlier. I find helpful to think of it as follows:
MVC
Model -- Data store, alerts Views of changes
View -- Displays model, provides hooks for user interaction
Controller -- Handles user input
You would use MVC more often in non-web apps, where lots of classes are interacting with eachother simultaneous.
In a web application MVC means MVT (Model-View-Template)
Model -- Strictly a data store, typically an ORM solution
View -- Handles web requests, provides for user input/output
Template -- Actually displays content (HTML, Javascript, etc.)
So in a web application the presentation is handled in the Template, the logic behind the application is handled in the View (or classes called by the view), and the model is responsible for holding data.
The reason why so many developers today can't get the knock of MVC is because the abbreviation of MVC was incorrectly stated from day one when it arrived into software development, but the concept is correct back then and also today. Since I am from the old school, let me explain it for you; when you are creating an object you first create a Model so the customer can View it, once it is approved you will have full Control on how the object is going to be made. That's how it is to this day in product manufacturing.
In today’s web application development such term should be VCM. Why! You View what's on the web browser, and then you click a button for action, that is known as the Controller. The controller alerts the Model, which is the instruction or logic to produce a result (that is your script). The result is then sent back to the user for viewing. In software engineering, you can refer to it as CMV; because the user won't able to view anything until the apps is compiled and installed. So we will need a Controlling device (PC); the OS as the Model and a monitor to View the results. If you can understand those concepts, MVC should start to look much more appetizing. I hope this concept will help someone to understand MVC.
I tend toward having the controller act as an intermediary between the model and the view, but generally this is literally a single line of code that connects the three together. If your model, view, and controller are properly decoupled it should make very little difference which you use.
I am working on a CMS using CakePHP and I want to create a dynamic menu which is the same on all the pages the user can access. So I figured out to create in the layout (since it shared among so many pages and view) but I don't seem to know how to acces the model and get the data from the database to construct the menu. any help is appreciated.
That's because for proper MVC separation* in Cake you're not supposed to access the Model from the View. The only part with access to data should be the Controller (via the Model), which hands it down to the View, which simply displays the data.
As such, using a beforeFilter callback in your global AppController to set() the data is probably the best choice.
In emergencies you can always access anything from anywhere by loading an instance of the needed Class using ClassRegistry::init, but you really shouldn't.
* Actually, in "proper MVC" there's no problem with the View getting data directly from the model. You shouldn't do that in templates necessarily, but View related code can well get data from the model to visualise the model state. It just doesn't really work that way in Cake, because Cake is not proper MVC and default Cake views are only templates.
An alternative could be requestAction, it allows you to call controller actions from views/layouts, and in those actions you can then access the desired model(s).