I have a design question about MVC and controllers
I have this two routes
Route::get('/foo/{id}', FooController#show)
Route::get('/bar/{id}', BarController#show)
But know, I would like to add another route for the index like this
Route::get('/', ???)
In this route, I need some information about the Foo and Bar models.
The question is, should I create a new controller for that route? like MainController?
In general, controllers are meant to respond to requests associated with a specific resource (model). Thereby, given your concrete example, two distinct scenarios apply.
The Foo and Bar models are required on the landing page (/ route): In this case, a dedicated controller would be a perfectly fine thing to do. Also, the use of a view model would be beneficial.
No information about application-specific models is needed on the landing page: You can still use a dedicated controller class to return your view, while another possibility would be the use of a lambda function:
Route::get('/', function () {
return view('landing');
});
It has always worked best for me to have a controller per resource type.
You have the resource 'foo' with FooController, and 'bar' with BarController. So for the root context resource, you aught to have a root controller.
This helps with separation of concern and keeps your code modularized.
Related
I was reading the Laravel documentation about middleware and at a certain point it said: "it would be more convenient to specify middleware within your controller's constructor."
I always assigned the middleware to the routes in the routing files because it felt easier to understand which functions were affected by the middleware.
I was wondering if there was a specific reason why the documentation says to put the middleware assignments directly in the Controller constructor or if it was just a matter of preference.
Its all depends on your own choice.
I always prefer to use middleware in route as a group, which keeps things centralized and I can find them easily.
Route::group(['middleware' => ['middleware1']], function () {
// your routes under middleware1
});
Route::group(['middleware' => ['middleware2']], function () {
// your routes under middleware2
});
I think it's a matter of preference, i like to assign the middleware to the route so i don't have to exclude certain methods in the controller plus it's much easier to know which routes use the middleware just by looking at the routes file.
it is more convenient to specify middleware within your controller's constructor.
This simply means you have more control over each methods if you use it in your controller's constructor, so that you can specify certain rules in method levels.
But when you are assigning to the routes you can only control the routes rules.
Thank you for your question, as mentioned before in most cases it is a decision made by the team you are working with.
From my own personal experience, I can only explain to you why we choose to use middleware definition in routes file instead of a controller.
In large applications, there are many cases of a dozen controllers.
With that being said, there can be cases where you have to change some middleware name. If you define it on route group you would have to change only one line of code, but if you define it in a constructor you would have to go to every controller and change it.
Some companies are using controllers to inject certainly classes into it. There can be a huge amount of injecting and assigning classes in the constructor itself.
That's why defining crucial checks should not be happening on this level of code.
I need a little help regarding design of MVC .
Most of the tutorials of MVC and CODEIGNITER are doing input validation in controller. Is it a good practice ?Suppose we implement REST or SOAP API then we are going to have different controllers, and for all those controllers I need to replicate my code. Later if any of the validation rule is changed, it will get rippled into all controllers. Shouldn't all the validation should be inside Model instead of Controller ?
One more thing I would like to ask. As I am trying to keep my functions as cohesive as possible, I am getting one to one relation between functions of model and controller. Is it ok or I am doing things wrong ?
Regarding doing input validation in Controller
Ans. Yes, that is the generally accepted practice in most MVCs. However, during the past few years, due to the advent of AJAX frameworks and more adoption of JavaScript, many UI validations get done in UI itself(called client-side validations). These are generally displayed as javascript alert boxes and do not allow user to go ahead unless he fixes these errors. So, I would say Controllers/View helpers are de-facto places where validations are done but you should consider client-side validations wherever feasible. It also saves you trips to the server.
If you expose the same as functionality as SOAP/REST
Ans. Now-a-days you can annotate the same controller methods to make them work as web service endpoints. So, your controllers can service both web-based requests and also SOAP/REST requests.
But one note of caution - your form-beans/backing beans should be very well designed. I have seen code where hibernate model objects are used as form-backing objects. This makes it tricky when you generate a WSDL out of the form-backing objects as hibernate model objects may have many linked entities and one ends up with very complex xml structures in the request/response.
But still, if you design your backing-beans as fine-grained, i.e. not having complex objects, then you should be comfortably placed in using your existing controller/controller methods as web service endpoints for both SOAP/REST.
Regarding the validations being inside Model layer
Ans. You can use this thumb rule to determine where to place which validations -
Business validations should happen in models/services
complex client validations, which are not feasible in client-side, should happen in controllers/view helpers
UI validations (formatting/empty checks) should happen via client-side/javascript validations
Regarding one to one relation between functions of controller and model/service
Ans. Its fine. Just remember to have one controller method talk to its respective model method. And if multiple models are needed to service a request, then that model method should act as an aggregator of information from multiple models i.e. the controller should contact its main model and the main model should contact other models.
Is it a good practice? In my experience yes.
One thing to keep in mind is that any given controller can display an number of different pages. For example, consider a "Dashboard" which could have multiple tasks each of which requires its own page.
A rough pseudo-codeish "Dashboard" controller might look like this:
class Dashboard extends CI_Controller {
public function __construct(){
parent :: __construct();
$this->load->helper(array('form', 'url'));
$this->load->library('form_validation');
$this->load->model('somemodel_model');
}
public function index(){
//displays a task selection page with links to various tasks
}
public function admins(){
//some kind of interface to display and edit admin level users
}
public function users(){
//CRUD for dashboard users
}
}
With this controller the task selection page is opened with baseurl/dashboard, adminstrator's page with baseurl/dashboard/admins and user CRUD with baseurl/dashboard/users. Because each of these share the same Class, code needed by all/many of these pages (like validation) can be implemented in the constructor and/or with private methods. You probably already know all this. Keep in mind that AJAX responders can also reside in a controller using the same technique.
In regards to keeping the validation rules DRY and easing the work required for changes to rules CI can store sets of rules in a config file for easy reuse in multiple situations. Read about it.
I need to call a controller say 'faq_view' inside admin controller as the URL structure admin/faq_view like this how I can do this?
e.g:
site.com/maincontroller/function
site.com/maincontroller/othercontroller/function
Then, just redirect the page. Else if you want to just call the function, call it via AJAX.
It depends what you exactly want to do. If you want to just invoke the function, its not the right way. Controller as it defines itself controls the flow of the pages that comes on sequence. Controller is responsible to send commands to its associated view to change the view's presentation of the model.
So, if you are saying you want to call controller within another controller, that should mean you are about to redirect to another page.
Updated answer:
Just assume you have new_function on maincontroller that calls the function from othercontroller. The function does not need to be defined on othercontroller.
Add the following line on routes.php.
$routes['maincontroller/new_function'] = 'othercontroller/new_function';
Now, you can call the function of othercontroller as maincontroller/new_function.
You can always call a controller inside another controller, but this only works for calling one controller as far as I have tried. Let's say you are trying to load a controller inside a controller. You can try this:
$this->load->library('../controllers/myothercontroller');
Then do this:
$this->myothercontroller->function_name();
That's it! You can now access any function inside myothercontroller (controller) in your current controller. I hope this helps too.
Your controllers are part of the presentation layer and should not contain application logic. That means you should never need to call a controller from another controller, instead refactor your application and move the domain logic to the model layer.
Now if you have a method that you need in multiple controllers, say for example you need a template method that automatically adds your header and footer views.
If that is the case, create a base class that your controllers extend.
If you are talking about just a routing issue, then just use the routes file for that. I don't like the CI automatic routing and it should be avoided as it will result in duplicate URLs for the same resource.
I'm trying to understand controllers in the new router system. I understand they exist to decorate models and present non-permanent state to the view/template for rendering. And I understand the conventions the Ember router uses to instantiate and set up single copies of each controller from route names. But does that mean you should never have more than one copy of a controller?
Here's my use case: I have a set of nested lists of items with complex non-persistent per-item state (different levels of collapsed / visible nesting, different editing modes, etc). I don't think this belongs in the view, and it's too complicated (because of nesting) to keep in a singleton controller -- so I was planning to have one controller instance per one view instance (all the same controller and view class though). Is this sound?
Second, simpler question. How do I access the controllers that Ember router instantiates? Previously, you could do App.get('router.postController') but that no longer works.
First Question
Not all controllers are singletons. There are cases where Ember.js creates non-singleton controllers for you.
One case is when using itemController with {{each}} helper:
{{#each model itemController="post"}}
<!-- template here -->
{{/each}}
This will create a new instance of App.PostController for every post item in the loop.
One other case is when you use the {{render}} helper and pass a model to it:
{{render "post" firstPost}}
{{render "post" secondPost}}
This will create a separate App.PostController instance for every {{render}}.
Second Question
It depends where you want to access them from.
From the route:
this.controllerFor("post");
From another controller:
App.CommentController = Ember.ObjectController.extend({
needs: ['post'],
test: function() {
return this.get('controllers.post'); // this returns the post controller
}
});
More info on that here: http://emberjs.com/guides/controllers/dependencies-between-controllers/
From the view:
this.get('controller');
I find myself needing to have a View expose its Model and Controller references. Is this the smell of bad design? Or is this considered "safe" practice?
For example: I have a list (composed of a ListView, ListController, and ListModel) and many list items (composed of a ItemView, ItemController, and ItemModel).
When I create the ItemModel, ItemView, and ItemController for each list item, I pass the ItemView instance off to the ListView. But, at some later point, my ListController needs a reference to the corresponding ItemController instance.
So, would it be more proper to pass both the ItemView and the ItemController in to ListView::addItem(), or just pass in ItemView and expose an instance method such as ItemView::getController()?
Or doesn't it matter? Is each approach equally viable? If followed to their logical conclusion, does either tactic result in an anti-pattern?
But, at some later point, my ListController needs a reference to the corresponding ItemController instance
Why? If you're decoupling your classes properly, you shouldn't need this.
Controllers almost always address a functional domain. An example of such a domain might be "Sales" or "Admin." In addition, MVC also supports the use of "Areas," which provides an additional hierarchical level of organization.
Adding references to controllers from other controllers is at cross-purposes with this organizational structure. If you need to combine functionality to make your code more DRY, ordinary refactoring will accomplish that. You can also inherit controllers from a base class containing common functionality.
In the mvc pattern the users request shall be routed to a controller, say invoicecontroller, that has actions.
Lets say the default action, Index, returns a list of invoices; the controller then creates a model with a list of invoice objects, instantiates the correct view and injects the model into the view.
Now it is the views turn to do its magic. It renders the best view it can with the data it has, which may include routes to one or more controllers.
In NO instance should the view (or model) do business logic themselves.
That said, I totally agree with Jakub. Hope that helps.
Considering you are not actually showing any code at all.
In my opinion, you should change your design. A controller is not supposed to communicate with another controller (directly), MVC dictates it: reference.
If you need to invoke a controller action from another controller, consider using delegates or composition. Instead of directly invoking the controller action.