a few years ago I wrote a PHP web application in a rather procedural way. As this project now gets reactivated and expanded I've made the decision to recode it using Laravel with its MVC structure. As I'm new to Laravel and MVC in general I'm working on converting my procedural approach in an object oriented approach.
After creating Models for each database table I'm faced with several questions:
When a page should be loaded that contains data from multiple models what is the best approach? Just call both models, get the data of both Models and send it to the view?
When I want to create a view that contains the aggregated data of multiple tables. In the actual version I just created a class that gets the data from both tables, adds some logic and returns the new array to the view. How would this be implemented in laravel? I didn't find some sort of wrapping model. Can you give me a hint how to implement this in laravel?
Thanks in advance for your help.
I would implement an Repository pattern for your problem. Take a look at my Repositories.
https://github.com/avored/ecommerce/tree/master/src/Models/Repository
At this stage my Repository doesn't contain multi table record fetch or store but eventually i will do it. Just for a starting point of view i hope it helps.
Related
Overview: I am building a CMS using PHP, and I am trying to implement this using MVC. I am trying to extend my code using this structure, as it represents an accurate representation of MVC and it is quite straightforward. To communicate with my database I use Domain Objects and Data Mappers.
Questions:
Is it really necessary to have a 1:1:1 mapping between a model, a view, and a controller?
Example: For a blog system, when displaying a blog entry page I would create a controller called DisplayEntryController, and a View called DisplayEntryView. The view would get its information from the BlogMapper class (which communicates with the DB to retrieve the current blog entry) and a CommentMapper class (which communicates with the DB to retrieve the comments for the current blog entry). Is this good practice, considering that view works with 2 model objects? If not what is the alternative? If yes, how can this be implemented in a generic way?
Can multiple controllers handle one page? For the example above, would it be possible to have a DisplayEntryController and a CommentController handling the relevant parts of a page displaying the blog entry? If yes, how would the 2 controllers coordinate?
Thank you in advance. Examples will be greatly appreciated.
Most PHP MVC implementations I've seen on the web use the page approach to organise their MVC. E.g. for the Home page, you have one view, one controller and one model. Routing for 1:1:1 mapping in MVC is straightforward, as you can enforce the location and naming of your MVC components, and when a request for the Home page comes it automatically looks for the following classes: HomeView HomeController and HomeModel.
This obviously doesn't work well in larger projects. How should routing be handled to support routing to multiple models (DataMappers), multiple views, without creating an overcomplicated router or adding a complex dependency injection layer?
Example: As discussed above, when displaying a blog entry you display
the blog entry code and the comment section. To achieve this, it
communicates with two DataMappers, the one which gets the blog entry,
and the one which returns the comments for the blog. How can the view
be assigned to work with these two datamappers to get the data from
the DB?
There is no requirement to have a 1:1 mapping of the model, controller and view.
MVC works of a concept of a tiered approach to handling your application, with each tier being handled by 'agents' to implement the way they see fit. To explain this further, consider the following scenario.
Assume you process data, then hand them over to someone to store. You don't care where they store it and how they store the data, as long as the information is available again when you need it. You can happily go about processing your data, and then say to them for example 'This is project data for Client X, store it,' and later say 'Can you give me the project data for Client X.'
SO MVC works on this approach, whether the data storage guys dump all data together or pack them away is not important to you. However, what is important is the interface between the two parties when sending and retrieving. For example, you could decide to store the information as either Client data, or Project Data, or both.
Likewise, you could have agents collecting data and handling it to you to process. You don't care how many interfaces they use (for example, phone, web, email, mobile devices), but you care about what data they hand you. (Of course a rule might dictate that only web information must be handled). So the interfaces for collecting data might be different.
Therefore, each agent can use the most efficient method (and even combine or split them) to get the system working in their side, and therefore there is no mapping of the data.
I'm using Codeigniter to flesh out a pretty large project (especially for a n00b). One issue I'm having is how to organise my files and methods. I've broken my project down into features - the app is a task management software so already we have basic features such as "Task", "Project", "User" etc.
The way I intend to do this is by creating controllers for each and then following CRUD methodology in each. So for example in Task we would have the following methods:
create()
read()
update()
delete()
This makes sense in my head. Now in terms of Views, should I have multiple views, or should I combine create and update into the same form? Also, where does non-View functionality go, such as setting cookies etc?
This is quite a specific question but if anybody has any more holistic guides on general structure convention for CodeIgniter projects I'd be very grateful.
I'd say you got it right. This is what I do.
I tend to use the same view for create and update, keep it DRY (don't repeat yourself) if you can.
Non-view related stuff that does not handle anything business-related goes in what I call helper-classes. If it's business related, I put all the logic into services, so I can unit-test them without being dependant of any framework (not sure how new you are at this, but oh well :) ).
You can also use Grocery Crud, a library that provides out of the box CRUD functionality for codeigniter.
It handles pretty good 1->n and n->n relationships so its convenient for small projects.
I don't know if you are familiar with it. If not give it a try. It will save you tons of time and effort.
My controller consists of these methods, which follows REST API guidelines:
read -> get all records.
find -> find record by primary key/id.
create -> show the form view.
store -> insert data from the form into the database.
edit -> show the form view, populated with current records' data.
update -> update data from the form into the database.
delete -> delete data from the database.
This is called Resourceful Controllers.
Yes, you can combine create and edit in same form. However, there are cases those require you to use different create and edit form. In that case, just make 2 separate forms.
And... like #Theodore suggested, GroceryCRUD is worth a try if you don't need too many customizations.
I am building a CRM using a framework (codeigniter) for the first time and I am having trouble determining where a certain module should go while maintaining the MVC methodology. The module automatically generates a new user (when a new company is created) and emails the log in details out to the supplied email address.
I am familiar with the idea of skinny controllers and fat models but to compile all the information needed the module must request data from several different tables as well as inserting data into several tables.
The scenarios I have considered so far:
The logic is in the model where most of the information comes from.
Create a totally new model that deals with just this module and the multiple tables required.
Place the logic in the controller that deals with creating a company.
Create a new library or helper and call the module when it is needed.
Skinny controllers and fat models seem to suggest that one or two are the right options but I was lead to believe that a model should only deal with one table in the database.
What is the right approach to ensure adherence with MVC?
Codeigniter allows you to be flexible with your MVC approach. So the answer is which option is:
Easiest for you (or your team) to understand
Easiest to code maintain
Easiest for someone else to understand
There's no point putting your code into a library, if you dont have any other libraries and dont understand libraries. Same as if all your models are "fat", but only point to one table, do you want this model to be the only one that also points to 4 other tables?
Personally, if this "logic" only ever happens in one place, then I would place it into the controller, and call the 4x models you need to do each bit of the code.
If this "logic" occurs in multiple places, I would place it into a library and call it when needed.
I'm new to using an MVC structure, and am developing my own MVC framework for a university project. I've got a database class that I can use to send a query to the database and return me an array of objects (PHP standard object class). I then want to display a list of the objects on an index page.
My question is, should this list of standard objects really be a list of models? Or are they fine as they are?
You don't have to create separate model classes just for the sake of creating model classes because they are in the MVC pattern name. If your solution also works when you simply pass the array of PHP standard object classes to your view, you should just use that. In that case creating model classes would just be extra work for no benefit. However, if you need additional functionality besides simply outputting a list of database results, you should consider creating actual models.
You should store data in your database and manipulate this data (create,update,read and destroy) with your models. I think you should better know what is MVC and what is for. You can read a bit here
depends... One could argue that most applications are very heavy on the Model side (Fat Models is an actual pattern), therefore it will not be enough to create a few stdObjects from an array, but actually map tables to object classes, so you can add useful methods to them.
I would recommend to take a look at Doctrine and try implementing a subset of features.
I have one doubt in zend framework. I need all model details from project which i have done in zend framework. Is there any possibility to get all model details in zend framework.
Please help me..
Thanks and regards,
Prasanth P
If by Model you mean you want to get the details about a DB Table, then yes. You can get this data by calling the following method from Zend_Db_Table
info() - Returns table information.
There is no method to say getAllDbTables. If you need this, you could write a custom Db Repository that knows all Db Tables and that can give you table instances and any info information you need about. This would have the additional benefit of decoupling concrete table instances from your using classes.
Keep in mind though that the M in MVC is not just the database. The M is the heart of your application. It contains application logic, domain objects, service layers, etc. The persistence layer is just one part of it.