How to solve the problem of composing a Controller class in PHP, which should be:
easily testable by employing Dependency Injection,
provide shared objects for end programmer
provide a way to load new user libraries
Look down, for controller instantiation with a Dependency injection framework
The problem is, that derived Controllers may use whatever resources the programmer wants to (eg. the framework provides). How to create a unified access to shared resources (DB, User, Storage, Cache, Helpers), user defined Classes or another libraries?
Elegant solution?
There are several possible solutions to my problem, but neither one looks to be a elegant
Try to pass all shared objects by constructor? (may create constructor even with 10 placeholders)
Create getters, settters? (bloated code) $controller->setApplication($app)
Apply singletons on shared resources? User::getInstance() or Database::getInstance()
Use Dependency Injection container as a singleton for object sharing inside the controller?
provide one global application singleton as a factory? (this one looks very used in php frameworks, hovewer it goes strongly against DI principles and Demeter's law)
I understand, that creating strongly coupled classes is discouraged and banished for :), however I don't know how this paradigm applies to a starting point for other programmers (a Controller class), in which they should be able to access shared resources provided to the MVC architecture. I believe, that breaking up the controller class into smaller classes would somehow destroy the practical meaning of MVC.
Dependency Injection Framework
DI Framework looks like a viable choice. However the problem still persists. A class like Controller does not reside in the Application layer, but in the RequestHandler/Response layer.
How should this layer instantiate the controller?
pass the DI injector into this layer?
DI Framework as a singleton?
put isolated DI framework config only for this layer and create separate DI injector instance?
Are you developing a framework yourself? If not, your question does not apply, because you have to choose from already existing frameworks and their existing solutions. In this case your question must be reformulated like "how do I do unit testing/dependency injection in framework X".
If you are developing a framework on you own, you should check first how already existing ones approach this issue. And you must also elaborate your own requirements, and then just go with the simplest possible solution. Without requirements, your question is purely aesthetic and argumentative.
In my humble opinion the simplest solution is to have public properties which initialize to defaults provided by your framework, otherwise you can inject your mocks here. (This equals to your getters/setters solution, but without the mentioned bloat. You do not always need getters and setters.) Optionally, if you really need it, you may provide a constructor to initialize those in one call (as you suggested).
Singletons are an elegant solution, but again, you must ask yourself, is it applicable in your case? If you have to have different instances of the same type of object in your application, you can't go with it (e.g. if you wish to mock a class only in half of your app).
Of course it is really awesome to have all the options. You can have getters/setter, constructors, and when initialization is omitted, default are taken from a singleton factory. But having too many options when not needed, is not awesome, it is disturbing as the programmer has to figure out which convention, option and pattern to use. I definitely do not want to make dozens of design decisions just to get a simple CRUD running.
If you look at other frameworks you will see that there is no silver bullet. Often a single framework utilizes different techniques depending on the context. In controllers, DI is a really straightforward thing, look at CakePHP's $helpers, $components variables, which instruct to inject appropriate variables into the controller class. For the application itself a singleton is still a good thing, as there is always just a single application. Properties less often changed/mocked are injected utilizing public properties.
In case of an MVC, subclassing is perfectly viable option as well: just as AppController, AppView, AppModel in CakePHP. They are inserted into the class hierarchy between the frameworks's and all your particular Controller, View and Model classes. This way you have a single point to declare globals for your main type of classes.
In Java, because of dynamic class loaders and reflection, you have even much more options to choose from. But on the other hand, you have to support much more requirements as well: parallel requests, shared objects and states between worker threads, distributed app servers etc.
You can only answer the question what is right for you, if you know what you need in the first place. But actually, why do you write just another new framework anyway?
Singletons are frowned upon when Dependency Injection is viable (and I have yet to find a case where a Singleton was necessary).
More than likely you will have control of instantiation of controllers, so you can get away with the mentioned $controller->setApplication($application), but if necessary you can use static methods and variables (which are far less harmful to the orthogonality of an application than Singletons); namely Controller::setApplication(), and access the static variables through the instance methods.
eg:
// defining the Application within the controller -- more than likely in the bootstrap
$application = new Application();
Controller::setApplication($application);
// somewhere within the Controller class definition
public function setContentType($contentType)
{
self::$application->setContentType($contentType);
}
I have made of a habit of separating static and instance properties and methods (where necessary, and still grouping properties at the top of the class definition). I feel that this is less unwieldy than having Singletons, as the classes still remain quite compact.
How about refactoring?
Granted that was not one of your options, but you state the code is a largely coupled class. Why not take this time and effort to refactor it to more modular, testable components?
As far as I understand, the Application class of yours should be the dispatcher. If so, I would rather use the controller constructor to pass an instance of the Application, so the controller would know who's invoking it. At later point if you want to have a different Application instance depending on whether the code is invoked from within CLI, you can have an ApplicationInterface which the Application\Http and Application\Cli would implement and everything would be easy to maintain.
You could also implement some factory pattern to get a nice implementation of the DI. For example, check the createThroughReflection method here: https://github.com/troelskn/bucket/blob/master/lib/bucket.inc.php
I hope this makes sense.
Regards,
Nick
You could also use a ControllerFatory in which you would give to your Application or Router/Dispatcher
Sou you could call $controllerFactory->createController($name);
Your Application would have no idea how to create your controllers the Factory would. Since you ca inject your own ControllerFactory in to your DI container you can manage all dependencies you want depending on the controller.
class ControllerFactory {
public function __construct(EvenDispatcher $dispatcher,
Request $request,
ResponseFactory $responseFactory,
ModelFactory $modelFactory,
FormFactory $formFactory) {
...
}
public function createController($name = 'Default') {
switch ($name) {
case 'User':
return new UserController($dispatcher,
$request,
$responseFactory->createResponse('Html'),
$modelFactory->createModel('User'),
$formFactory->createForm('User'),...);
break;
case 'Ajax':
return new AjaxController($dispatcher,
$request,
$responseFactory->createResponse('Json'),
$modelFactory->createModel('User'));
break;
default:
return new DefaultController($dispatcher, $request, $responseFactory->createResponse('Html'));
}
}
}
So you just need to add this factory in your DI container and pass it to your Application.
Whenever you need a new controller you add it to the factory and if new dependencies are required you give them to the factory through your DI container.
class App {
public function __construct(Router $router,Request $request, ControllerFactory $cf, ... ) {
...
}
public function execute() {
$controllerName = $this->router->getMatchedController();
$actionName $this->router->getMatchedAction();
$controller = $cf->createController($controllerName);
if(is_callable($controller, $actionName)) {
$response = $controller->$action(request);
$response->send();
}
}
}
This is not production code, I haven't tested, but this is how you decouple your controllers from your application. Notice here though that there is one bad coupling here because my controller return's a response and I execute the response in the App. But like I said this is just a small example.
It is usually a good idea to pass factories for Models, Forms, and Controllers to their respective parents, because you will end up loading all your object Graph at bootstrap time wich is really bad and memory consuming.
I know this answer was already approved, but it's my 2 cents on the subject
There is a good article on the subject
http://miller.limethinking.co.uk/2011/07/07/dependency-injection-moving-from-basics-to-container/
Related
I'm currently using Laravel and have a pretty good general grasp now on how the dependency injection and service container works now. I see it working very well when programming to interfaces, but what about concrete classes?
I utilize a service layer between my controllers and models. The point of the service objects was so that I could easily reuse their methods elsewhere, like in a different controller. But there are cases where I also need to use a service inside another service.
So I've been using the constructor for the dependency injection inside my services. The issue I kind of see is that sometimes I only need a service (inside one of my other services) for 1 method. So doing it in the constructor makes it rather large. On the other hand, since I've been setting these parameters in the constructor, I can't simply new-up an instance on demand, since it requires those parameters. For example, let's say I have an OrderService class, and for the constructor, I see two ways I can go about it:
public function __construct(FileUploadService $fileUploadService)
{
$this->fileUploadService = $fileUploadService;
}
or
public function __construct()
{
$this->fileUploadService = new FileUploadService;
}
I've mostly been doing it the first way, but have been thinking about the second. If I ever needed this OrderService somewhere else in the app, I can't simply create a new instance since it relies on the FileUploadService, unless I create a new instance of that too. But you can see that it will start to cascade without the dependency injection, because what if the FileUploadService depends on something also? It's just easier to resolve it out of the container.
Maybe there's something I'm missing, because it almost feels like a catch 22 in some ways. I'd like to note that a majority of these classes I'm injecting are concrete classes, so I don't need to swap them out at any particular point.
I've thought about just creating a new instance in the constructors for each service I need, that way I can also new-up the instance without providing parameters. But I like to follow best practices, so I was wondering what other experienced developers thought about this.
I have read a lot of SO topics about this already, but still haven't found (or have been able to create) a proper answer.
I am working on a small MVC framework and I want some global class/object that I can call from my controllers (but maybe models too).
There are a couple of routes I can take:
Global variable
Static class/Registry
Dependency injection
The internet seems to agree that the DI is the best route to take. I think I have grasped the idea, but am not comfortable yet. So I want to throw in some background information; I will probably be the only one working on the project, it is a small project, all my controllers extend the main Controller (so I could just load one library like class there).
As a concrete example, I want to have an array of categories. So I started out with putting that array in the CategoryController. But now I noticed I kinda want to use that array in my frontview and in ProductController as well. Obviously I don't want to load all of CategoryController into ProductController.
You could also say I could put that array in some kind of configuration or settings file, because of the simpleness of this example, but that's why it's an example. I will probably expand on it with more functionality.
So to summarize: In PHP (specifically inside a MVC model) how can you give your classes (mainly Controllers) access to some kind of common class or other sharable functionality.
Your controllers are created by "something" (usually a front controller). So when the controller is created, you could inject a dependency injection container.
And in your configuration/bootstrap (before the controller is created), you should add you categories to the container.
That way you can access the categories from every controller.
Please note that this is a simple example that doesn't totally fit the spirit of dependency injection. The best solution would be to inject directly the categories (instead of injecting the container). But that can become a lot of work if you generalize that pattern (lots of dependencies to handle in your front controller).
A solution would be to use a dependency injection framework that could do that for you.
For example I work on a DI container that lets you inject stuff with annotations (PHP-DI), but there are several other libraries for DI so you have a choice.
My 2 cents:
In a small self-made mini-framework I have done some time ago, I have created a global singleton class named Application, and anything/everything which should be accessible from anywhere/everywhere was a property or method of this class.
In my case, there was a $db property for database access, a $user property to access the user data and methods, an $input property for a "powered" $_REQUEST access, and so on.
Of course, you have many other options, suitable for different scenarios. This approach simply worked fine for me on that occasion.
Now, if you want to access a controller from another controller, this really sounds strange. This "thing" that you want to access should be a model class, a library class, or anything else, but it should not be "locked" inside a controller class. Indeed, the controller should be "as thin as possible", and focus on calling the appropriated methods from other classes, based on the user input (request) and then calling some output method to generate and send the answer (response).
Finally, although I've read some criticism and complaints about it (as well as praises too), I do make use of static methods a lot, mainly for classes which are more "helpers" than anything else.
I'm working on building a PHP framework that behaves according to MVC principles and utilizes dependency injection. I think I have the front-controller part down; there is a working router that instantiates a controller instance and calls the appropriate action based on the requested URI.
Next up is dependency injection. I want to implement a Container that resolves dependencies using reflection. In doing so, I think I'm running into a problem with my controllers.
There are a number of what I call "system dependencies" that need to be available to derived controller classes. I haven't actually created all these dependencies yet, but it seems sensible that controllers have access to services like an InputProvider (to encapsulate get/post params or command line arguments), and maybe an Output dependency.
Ideally, I'd use the framework's Container to inject these dependencies into the constructor of the controller - but this is where I run into problems.
If I use constructor injection for system dependencies in the controller, then I'm forcing derived controllers to manage the base controller's dependencies if they implement a constructor of themselves. That doesn't seem to be the most user-friendly.
The other option is to use setter injection for system dependencies, but then derived controllers won't have access to these system dependencies if they should have need of them in their constructor.
The only solution I see that offers the best of both worlds is to make my controllers singletons. They'd have a private constructor so I can safely use setter injection without worrying about the constructors of derived classes. Instead, there would be an overridable initialize() method (assuming I get method injection working somehow), that basically fulfills the role of constructor (as in, an initializer for the derived controller). This way, constructor injection is replaced by method injection in the initialize() method, where all system dependencies would be available, without requiring the derived controller to manage them.
But then, a quick google search seems to unanimously say that singleton controllers are bad practice. I'm very unsure on how to proceed. I am probably overengineering this, but apart from wanting my application to be future-proof and maintainable, I also see it as a little exercise in applying best practices, so I'd like to do things "properly".
I think the best practice in this case would be to pass the responsibility of managing the required system dependencies to the derived controller. A dependency should probably only be instantiated if the derived controller actually has need of it. Why inject an InputProvider in the base controller if it is possible that a derived controller is never even going to use it? But at the same time, I keep coming back to user friendliness, and how nice it is to simply always have a $this->input member available, such as in a framework like CodeIgniter.
I highly appreciate any and all contributions to my dillemas. I also apologise for the wall of text, but I couldn't think of any code examples that would make the job of explaining any easier, since it's all so abstract to me right now!
Sincerely,
A severely torn individual
Several solutions are possible:
forbid controllers to use __construct(): make it private public final, and make controllers override something like init() and call it from the constructor. Then the constructor would inject all the dependencies (reflection? other stuff?), so that they are all ready in init().
you can use an existing DI library like PHP-DI (disclaimer: I work on that) that will allow you to define dependencies but have them available in the constructor (magically, yes).
Something like that:
<?php
use DI\Annotations\Inject;
class FooController {
/**
* #Inject
* #var Bar
*/
private $bar;
public function __construct() {
// The dependency is already injected
$this->bar->sayHello();
}
public function setBar(Bar $bar) {
return $this->bar = $bar;
}
}
For example that is how I work with Zend Framework 1. I can't use the constructors, so I inject into properties. Here is the ZF1 integration project.
After reading a trillion vague tutorials on Dependency Injection Containers, I feel as though I'm still not fully getting the point.
When it comes to things that are application specific (like models, controllers, etc), how should I manage the auto-injection of dependencies?
I happen to have a LARGE website, with maybe 30-40 different types of models...do I really create a single application dependency manager to handle each of these different types?
I have had people tell me that DIC's are not meant for domain stuff, but more for framework stuff, and I have also heard the opposite.
Which is "right"?
BONUS QUESTION:
If DIC's aren't applicable for domain layer objects (like models), how do you pass dependencies to the domain layer objects?
Maybe not exactly what you are looking for but here is an example usage of Dependency Injection Container (DIC)
Let's say I have a Database class and a Cache class. I need to be able to access my database and my Cache class inside of my other classes (models, controllers, etc).
This is a situation where a DIC would come in handy, I can simply store my Database and Cache class inside the DIC class and pass that DIC class into any other class that needs access to the objects that it holds
It's not very clear what the question is, but I'll try.
When it comes to things that are application specific (like models,
controllers, etc), how should I manage the auto-injection of
dependencies?
Do you use a DIC? Did you write one, or do you use a library?
Maybe a library would help, I am the author of PHP-DI so I'm biased, but the library helps me auto-inject dependencies.
For example I can write:
class UserController
{
private $formFactory;
public function __construct(FormFactory $formFactory) {
$this->formFactory = $formFactory;
}
public function createForm($type, $data, $options) {
// $this->formFactory->...
}
}
In that situation, the DIC can detect what dependencies your controller want, and autoinject them. That makes life easier.
I happen to have a LARGE website, with maybe 30-40 different types of
models...do I really create a single application dependency manager to
handle each of these different types?
Why would you need that? I don't understand the need, maybe you need to explain a bit more what's the problem.
I have had people tell me that DIC's are not meant for domain stuff,
but more for framework stuff, and I have also heard the opposite.
Which is "right"?
IMO there's no difference between "domain stuff" and "framework stuff". The only thing that is hard though, is having a DIC injecting stuff in an entity, because that's not a "singleton" (not in the Singleton Pattern way): these objects are not "managed" by the DIC, you can create instances manually everywhere in your code. Example:
$user = new User();
If the User class needs a service, then everywhere in your code you have to do:
$user = new User($service);
On the contrary, you never need to create a service manually (you never need to call "new"), so you can let the container create the instance and inject everything.
I'm not very happy with my answer as it's a bit vague, but I have trouble identifying really what's your problem. Maybe you should give code examples, or at least explain a bit more.
PS: I have struggled to understand DI and what is a DIC too, don't settle for a "I think I get it a bit more now, though not totally", I did the same and it took me months to finally understand.
If it helps, read the introduction text at http://mnapoli.github.io/PHP-DI/ and maybe also: http://mnapoli.fr/controllers-as-services/ (not directly related, but it can help)
I'm currently working on an oophp application. I have a site class which will contain all of the configuration settings for the app. Originally, I was going to use the singleton pattern to allow each object to reference a single instance of the site object, however mainly due to testing issues involved in this pattern, I've decided to try a different approach.
I would like to make the site class the main parent class in my app and call it's constructor from within the constructors of the child classes, in order to make all the properties available whenever needed.
When run for the first time, the class will only contain the db details for the app. To get the remaining values a query must be performed using the db details. However, any subsequent instances will be clones of the original (with all values). I may also set a Boolean flag to perform the query again a completely new instance is required.
Would this be a viable alternative to the singleton and would it solve the testing issues it causes? This is all theory atm, I haven't started to code anything yet,
Any thoughts or advice greatly appreciated.
Thanks.
I think a better way is to have an 'configuration' object that will get passed to the constructors of all your other classes. So, almost something like a singleton, except it's explicitly created and passed only to classes that need it. This approach is usually called dependency injection.
After trying many different techniques, what I have found functional and reliable is this method:
Use a bootstrap, or initialization file. It is located in the ROOT of the site with the proper permission and safe-guards against direct access.
All pages in the site first include this file. Within it, I create all my global objects (settings, user), and reference them from there.
For example:
// OBJECT CREATION
$Config = new Configuration();
$User = new User();
Then within classes that require these objects:
public function __construct($id = NULL) {
global $Config; // DEPENDENCY INJECTION SOUNDS LIKE AN ADDICTION!
if($Config->allow_something) {
$this->can_do_something = true;
}
if(NULL !== $id) {
$this->load_record($id);
}
}
Notice that I just access these global objects from within the class, and how I don't have to include the object variables as the first constructor parameter each and every time. That gets old.
Also, having a static Database class has been very helpful. There are no objects I have to worry about passing, I can just call $row = DB::select_row($sql_statement);; check out the PhpConsole class.
UPDATE
Thanks for the upvote, whoever did that. It has called attention to the fact that my answer is not something I am proud of. While it might help the OP accomplish what they wanted, it is NOT a good practice.
Passing objects to new object constructors is a good practice (dependency injection), and while "inconvenient," as with other things in life, the extra effort is worth it.
The only redeeming part of my answer is use of the facade pattern (eg. DB::select_row()). This is not necessarily a singleton (something the OP wanted to avoid), and gives you an opportunity to present a slimmed down interface.
Laravel is a modern PHP framework that uses dependency injection and facades, among other proven design patterns. I suggest that any novice developer review these and other such design practices thoroughly.