Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
Since Symfony 5.1 injecting the Container by autowiring the Psr\Container\ContainerInterface is deprecated see https://symfony.com/doc/current/service_container.html#public-versus-private-services
In case a service still needs access to the Container, does it needs to be injected by hand for the future, or is there another, more convenient, way to inject it?
One option would be to use Autowiring by Name and inject it, whenever there's a variable called $container, however that feels like a hack.
Question: What is the best practice of giving a service access to the container, if it still depends on it in Symfony 5.1+?
Making your services container-aware has been discouraged for quite a while.
As a general rule, you should avoid making your services container-aware and instead directly pass in the required services in the constructor or via setter-injection. In some cases using a container as a service locator can be useful though. For example when you use the AbstractController or when you have a service that takes in a lot of "registered" services, e.g. for handlers/senders in a Message Bus. For those cases Symfony provides a Service Locator/Subscriber: https://symfony.com/doc/current/service_container/service_subscribers_locators.html
The major difference is, that you have to define the services for the locator/subscriber instead of having all services available, like in Symfony's internal container. You can however tag services that should go into your service locator/subscriber and then collect these tagged services, so they will be passed automatically. See: https://symfony.com/doc/current/service_container/tags.html#reference-tagged-services
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
How to make PDO instance available throughout entire application in PHP ?
I'm using autoload from PS4 allowing to access any class in the application by using :
use Namespace\ClassName;
In the case the class has static method, I can use this very handful way to call the method :
Class::method();
I would like to be able to initiate a PDO connection once in the application and be able to use it everywhere.
I already have a PDO class with all the convenient methods to request the database. When this class is instanciated, it connects to the database and store the connection in a class attribute.
Some solutions are available but it has some drawbacks :
1) Instanciate the PDO once and pass it to the constructor of classes.
I'm not a big fan of this strategy because it forces me to instanciate classes using
$instance = new Class($pdo);
Class->method();
Which is less pretty than Class::method();
2) Make pdo instance Global
I don't know why but I saw everywhere it was a bad idea. Instinctively I'm not a fan of it too.
3) Pass it to methods while using them.
It looks very dirty to me and not convenient at all.
Do you have any idea on how to achieve it ?
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I just learned about Laravel Service Containers and it seems like a great functionality.
as I understood it prevents us from rewriting 50 controllers when we should modify a commonly used entity or variable throughout the project.
the problem being is that I don't see a proper Use case for this feature, I mean if you have a piece of data or an entity that you're repeatedly using: this can be customized through a model
so when should I use service containers in laravel ?
what are the Pros and cons of this functionality ?
as I understood it prevents us from rewriting 50 controllers when we should modify a commonly used entity or variable throughout the project.
I do not believe you understand it correctly.
Service Containers are just a fancy term that Laravel came up with to describe dependency injection. The major benefit is for unit testing and its biggest competitor is the facade pattern that Laravel also uses. The biggest benefit of dependency injection is that you can mock expectations without requiring additional "scaffolding" code that bootstraps the test. More information about using dependency injection for unit testing: https://medium.com/philipobenito/dependency-injection-as-a-tool-for-testing-902c21c147f1
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Now, im facing three issues about my symfony 2 application architecture using Doctrine 2. This is a one bundle application.
I will use some controllers of course, but I need some special controller "BeforeController" to be called before the others. In the "BeforeController" I want to place some initialize methods. Is it best practice to extends controllers by "BeforeController"?
I want to create some services in ServiceContainer. For every entity which I have, I want to create own service (e.g. There is Products entity, so I will create Product service, which provides methods manipulating with products and so on), if is it good way. Or is it in Controller compentence?
Can somebody explain me, what is in controller or in service competence?
I should like to create some logical and intuitive architecture. Maybe any class diagram should help me.
Can somebody describe me some best practices about it?
From documentation:
kernel.controller Event, and example: Before filters with the kernel.controller Event,
Service: Service base info and more: What is a Service? Controller base info, and additionally Action. It's nothing wrong with creating separate services for each entity if you really need it.
As above.
I recommended this video from SymfonyCon Warsaw 2013 How Kris Writes Symfony Apps.
Hope this help.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I am currently building a web app in php using Laravel-4, however, I suspect that this question is applicable to other languages and frameworks as well.
I have read about dependency injection and Facades and understand the necessary coding in each case. What I am not clear on is when you should use one over the other?
What the advantages/disadvantages or simply the reasons for using either dependency injection over the Facade design pattern?
Many thanks
Facades are used to make interactions with classes easier to read and use. It makes the code appear that you're using a bunch of static methods to interact with a class without instantiating it when in actuality you are calling methods on an existing object.
Dependency injection is used to, as the name implies, inject the dependencies of a class into the class. This is done through the constructor. You inject classes into another class to allow the class to use the functionality from the injected classes. This becomes powerful when you start injecting an interface into a class. Then you can create a class based on the interface and inject it into the class. This way, if you need to change the way the injected class works, you can create a new class based on the interface and inject it. Since you code is based on the injected interface, it will ensure that the class the received the injections will continue to work without needing to be changed.
This is most notable in Laravel 4 if you create a repository which is based on an interface for the Eloquent engine. You can inject that repository into a controller and use the methods on the interface to get the info you need. then if you ever want to switch to something like Redis, all you have to do is make a new class based on that interface that uses the Redis engine instead and then inject that class. The controller will never need to be changed.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I'm building an Authentification library that's going to have around 45+ methods for dealing with user related stuff. However I've been wondering if it's actually recommendable to keep everything on a single file.
Is there a benefit on splitting my class into several subclasses and load them when needed?
I can always for example split the class into "mandatory" elements and the elements that only registered users need...
For example:
Mandatory Methods:
$user->is_logged()
$user->login()
$user->register()
Methods for Register...
Methods for logged-in user.
It just depends on how you want to be including the class file(s) in your pages. If you want one simply include() statement for every page, then keep it all in one file. Unless your library is HUGE, the overhead from the other classes shouldn't be too much.
If you do it the other way, you'll simply be including different files based on the status of the session of the client.
Personally, I'd split them up as it's easier to edit them that way, but it's totally up to you.
I'd go with the class/sub-class option.
You could then use a factory to return the correct type of user object based on the current URL or by simply specifying the desired type of user object if your particular setup doesn't lend itself to this.