For those of you that are familiar with the building of the Symfony container, do you know what is the differences (if any) between
Tagged service Collector using a Compiler pass
Tagged service Collector using the supported shortcut
Service Locator especially, one that collects services by tags
Specifically, I am wondering about whether these methods differ on making these collected services available sooner or later in the container build process. Also I am wondering about the ‘laziness’ of any of them.
It can certainly be confusing when trying to understand the differences. Keep in mind that the latter two approaches are fairly new. The documentation has not quite caught up. You might actually consider making a new project and doing some experimenting.
Approach 1 is basically an "old school" style. You have:
class MyCollector {
private $handlers = [];
public function addHandler(MyHandler $hamdler) {
$handlers[] = $handler;
# compiler pass
$myCollectorDefinition->addMethodCall('addHandler', [new Reference($handlerServiceId)]);
So basically the container will instantiate MyCollector then explicitly call addHandler for each handler service. In doing so, the handler services will be instantiated unless you do some proxy stuff. So no lazy creation.
The second approach provides a somewhat similar capability but uses an iterable object instead of a plain php array:
class MyCollection {
public function __construct(iterable $handlers)
# services.yaml
App\MyCollection:
arguments:
- !tagged_iterator my.handler
One nice thing about this approach is that the iterable actually ends up connecting to the container via closures and will only instantiate individual handlers when they are actually accessed. So lazy handler creation. Also, there are some variations on how you can specify the key.
I might point out that typically you auto-tag your individual handlers with:
# services.yaml
services:
_instanceof:
App\MyHandlerInterface:
tags: ['my.handler']
So no compiler pass needed.
The third approach is basically the same as the second except that handler services can be accessed individually by an index. This is useful when you need one out of all the possible services. And of course the service selected is only created when you ask for it.
class MyCollection {
public function __construct(ServiceLocator $locator) {
$this->locator = $locator;
}
public function doSomething($handlerKey) {
/** #var MyHandlerInterface $handler */
$handler = $serviceLocator->get($handlerKey);
# services.yaml
App\MyCollection:
arguments: [!tagged_locator { tag: 'app.handler', index_by: 'key' }]
I should point out that in all these cases, the code does not actually know the class of your handler service. Hence the var comment to keep the IDE happy.
There is another approach which I like in which you make your own ServiceLocator and then specify the type of object being located. No need for a var comment. Something like:
class MyHandlerLocator extends ServiceLocator
{
public function get($id) : MyHandlerInterface
{
return parent::get($id);
}
}
The only way I have been able to get this approach to work is a compiler pass. I won't post the code here as it is somewhat outside the scope of the question. But in exchange for a few lines of pass code you get a nice clean custom locator which can also pick up handlers from other bundles.
Related
Intro moved to the bottom:
Right now I'm working on a small system, that manages orders and products.
I'm trying to refactor chunks of code from the controller and into business and service classes, here's what I'm trying to pull
/src/domain/bundle/Business/
/src/domain/bundle/Services/
So in the Business, I will have an Order Class, that does some calculations, some of these calculations required data from the database (on the fly).
Here's exactly the problem I have:
The controller loads an array of Orders that needs processing
The controller sends orders that needs processing to the OrderBusiness class
The OrderBusiness class needs to get the product(s) price from the database
Now I'm stuck..
What I'm attempting to do, is I made a ProductsService class, that returns the required product and price from the database, but how can I call this class from my OrderBusiness class without defining my OrderBusiness class as a service and injecting it with the ProductsService class
Intro:
I'm quiet sorry if my questions seems to be a little general and ignorant.
I've been using Symfony2 for less than a year now, and some things I can't wrap my mind around, even after reading the documentations, and a lot of the questions.
You can do whatever you want but it's often better to stick to Symfony's default way:
Controller gets data from request, validates it, calls other classes, and renders request (usually using Twig or JsonResponse::create).
To get data from database there are repositories. It's good when they return plain old PHP objects (POPO). Usually are managed with Doctrine magic.
To process objects (aggregate, filter, connect to external services, etc) you can create services. You don't to suffix them with Service (any class name is OK) and put to Service folder.
When you create many simple classes that follow "Single responsibility principle" it's convenient to connect them with dependency injection. Then your classes don't stick to each other too much and it's easy to swap one class with another without changing code in all files, also good for testing.
Symfony: Dependency Injection
So, Symfony not requirements for define all classes as services! The service layer - DependencyInjection
You must register a new service in container for access to this service in another systems/services/business logic. Performance for this: the service will be created (new SomeService) only one time, and cache this object in inner cache layer.
If you want create a new service instance for each time, you can add scope: prototype to service definition
This system vary good for many references between services.
You problem/solution:
In best practices - in no way!
As solution: you can use singlton, or use static services.
But, i recommend use dependency injection pattern layer for this problem and create all classes for each logic. Reasons:
Single responsibility
Easy testing with PHPSpec/PHPUnit (because each class - one business logic).
You can inject common logic in __constructor without parameters $this->dependencyService = new SomeService()!
If you not want define service in container, but another service have reference, you can define dependency service as private public: false
Dynamical services (creates via factory) for any condition (request, user, scope, etc...)
In my case:
As example from my another project (Orders, Products, Variants...)
I have:
ProductRepository - for load products, variants.
PriceCalculator - for calculate price for product (I loads price from product property, but you can inject PriceLoader service for loads prices from another storages).
OrderProcessor - for processing order.
Controller:
class OrderProcessingController
{
private $productRepository;
private $orderProcessor;
public function __construct($productRepository, $orderProcessor)
{
$this->productRepository = $productRepository;
$this->orderProcessor = $orderProcessor;
}
public function processForProduct($product)
{
$product = $this->productRepository->find($productId = $product);
if (!$product) {
// Control for product not found
}
$this->orderProcessor->processForProduct($product);
return new Response('some html');
}
}
In this we only load product, control if not found and call to process. Vary simple and easy testing.
Order processor:
class OrderProcessor
{
private $priceCalculator;
private $priceLoader;
public function __construct($priceCalculator, $priceLoader)
{
$this->priceCalculator = $priceCalculator;
$this->priceLoader = $priceLoader;
}
public function processForProduct($product)
{
$price = $this->priceLoader->loadForProduct($product);
$price = $this->priceCalculator->calculateForProduct($price, $product);
// Some processing
return $order;
}
}
In this class - we load price for product, calculate, create order and call to another processing if necessary. Vary simple and easy testing.
P.S.
Right now I'm working on a small system, that manages orders and products.
Can use any microframework? Silex as example or Symfony Microframework, and completely unsubscribe from dependency injection layer?
Now I'm stuck.. What I'm attempting to do, is I made a ProductsService
class, that returns the required product and price from the database,
Use repository class for business queries. Don't mix application layers. You can also define the repository as a service.
When class represents the general interface or represents an algorithm (e.g. business) define it as service.
I'm a newbie on symfony, And I don't understand the advantage of use service instead of write the cose in Controller
For Example, I Have a service that Create Log, with a code like this:
$path = $root.'/../web';
$fs->touch($path.'/log.txt');
$this->file = $path.'/log.txt';
file_put_contents($this->file, $msg, FILE_APPEND | LOCK_EX);
I can put this login in service with DIC ($fs is FileSystem service), or I can Put this Login on my Controller.
Of course If i Need to log often I have to write the same code. The main advantage is decoupling?
Thanks a lot
Suppose you have a Bar class which uses BasicLogger.
You have a few ways to get access to this logger, lets start with the most simple option:
<?php
class Bar
{
public function bar()
{
$logger = new BasicLogger();
$logger->log("foo");
}
}
This is bad practice because we are mixing construction logic with application logic. It still works, but it has the following drawbacks:
It mixes responsibilities.
Bar becomes hard to test and cannot be tested without side effects.
We cannot dynamically change loggers (code is less reusable).
To solve these drawbacks, we can instead require our Logger class through the constructor.
Our code now looks like this:
class Bar
{
private $logger;
public function __construct(Logger $logger)
{
$this->logger = $logger;
}
public function bar()
{
$this->logger->log("foo");
}
}
Great, our class is no longer responsible for creating the logger, we can test our code without side effects (and make assertions against how the logger was used) and we can now use any logger we like.
So now we use our new class all over the application.
$logger = new Logger();
$bar = new Bar($logger);
Look familiar?
Again we are mixing construction logic with application logic, which we already know is bad.
Not only that, but something even worse is happening here, Code duplication.
Thats right. and every time we want to use our Bar class, the duplication gets worse.
The solution? Use the Service container
Registering your logger as a service would mean that all of your code that needs logging functionality is no longer dependent on your specific logger, responsibilities will not be mixed, code duplication will be reduced and your design will become more flexible.
The main goal and advantage of services is that keep reusable code and use a DRY approach.
Of course, there is a lot of other advantages that you discover progressively as you use them.
Services are accessible from whatever context of your application that can accesses the service container, not only controllers.
If without the service the few lines of code you give would be duplicated in several methods/contexts, you should keep your service.
Otherwise, delete it and do your logic in the specific method.
I think the better approach to use them is at your own feeling.
Don't try to create services in prevention, use them to solve a real need.
When you have a block of code that is duplicated, you should naturally avoid it by creating a service (or other AbstractController that your controllers can extend and inherit the code block) .
The goal is: Always keep a light code and avoid duplicates as possible.
For that, you can use the powerful services of Symfony, or just use the inheritance of classes and other POO principles.
Using SimpleIoc I want to automatically register all classes that implement a particular interface. I couldn't see a method on SimpleIoc's container to do this automatically so I put a some code together to iterate through the types to be registered. Unfortunately the code's not happy (see the commented line).
var types = AppDomain.CurrentDomain.GetAssemblies()
.SelectMany(s => s.GetTypes())
.Where(typeof(IFoo).IsAssignableFrom);
foreach (var type in types.Where(x=>x.IsClass))
{
container.Register<IFoo, type>(); //this line won't compile as type can't be resolved by the compiler
}
I realise there are less elegant ways of registering classes (such as just hard coding "container.Register" to register each class to the interface) but I'd like to be able to add new implementations without having to keep updating the ioc installer code. It would also be useful, at some point, for me to be able to register classes in other assemblies using the same method.
Any idea what I have to change to make this build (or is there a simpler/more elegant way to do this)?
UPDATE fex posted this comment:
"you can always iterate over types (like you do in your question) and create it with reflection (in your factory class) - (IFoo)Activator.CreateInstance(type); - in fact that's how service locators / ioc containers do it internally (in simplify)."
I've now updated my code to the following which works, with one caveat (the implementations must have a parameterless constructor, and dependencies must therefore be satisfied by the factory that I'm then using to serve up instances implementing IFoo). I've included the factory registration too for info.
Updated code:
// Get the types that implement IFoo...
var types = AppDomain.CurrentDomain.GetAssemblies()
.SelectMany(s => s.GetTypes())
.Where(typeof(IFoo).IsAssignableFrom);
// Register these types and use reflection to instantiate each instance...
foreach (var type in types.Where(x=>x.IsClass))
{
var t = type;
container.Register(() => (IFoo)Activator.CreateInstance(t), t.ToString());
}
// Inject all registered instances of IFoo into IFooFactory when it's instantiated.
// Note that instances of IFoo must have their own dependencies satisfied via the
// factory at runtime before being served by the factory.
container.Register<IFooFactory>(
() => new FooFactory(container.GetAllInstances<IFoo>()));
Using https://insight.sensiolabs.com to scan / check my code, I get the following warning:
The Doctrine Entity Manager should not be passed as an argument.
Why is it such a bad practice to inject the Entity Manager in a service? What is a solution?
With respect to the comment that repositories cannot persist entities.
class MyRepository extends EntityRepository
{
public function persist($entity) { return $this->_em->persist($entity); }
public function flush () { return $this->_em->flush (); }
I like to make my repositories follow more or less a "standard" repository interface. So I do:
interface NyRepositoryInterface
[
function save($entity);
function commit();
}
class MyRepository extends EntityRepository implements MyRepositoryInterface
{
public function save ($entity) { return $this->_em->persist($entity); }
public function commit() { return $this->_em->flush (); }
This allows me to define and inject non-doctrine repositories.
You might object to having to add these helper functions to every repository. But I find that a bit of copy/paste is worth it. Traits might help here as well.
The idea is move away from the whole concept of an entity manager.
I am working on a quite a large project currently and have recently started following the approach with repositories that can mutate data. I don't really understand the motivation behind having to inject EntityManager as a dependency which is as bad as injecting ServiceManager to any class. It is just a bad design that people try to justify. Such operations like persist, remove and flush can be abstracted into sth like AbstractMutableRepository that every other repository can inherit from. So far it has been doing quite well and makes code more readable and easier to unit test!
Show me at least one example of a service that has EM injected and unit test for it looked correctly? To be able to unit test sth that has EM injected is more about testing implementation than anything else. What happens is then you end up having so many mocks set up for it, you cannot really call it a decent unit test! It is a code coverage hitter, nothing more!
I'm trying to use Groovy mixin transformation on a spring-mvc controller class but Spring does not pickup the request mapping from the mixed in class.
class Reporter {
#RequestMapping("report")
public String doReport() {
"report"
}
}
#Mixin(Reporter)
#Controller
#RequestMapping("/a")
class AController {
#RequestMapping("b")
public String doB() {
"b"
}
}
When this code is run .../a/b url is mapped and works but .../a/report is not mapped and returns HTTP 404. In debug mode, I can access doReport method on AController by duck typing.
This type of request mapping inheritance actually works with Java classes when extends is used; so why it does not work with Groovy's mixin? I'm guessing it's either that mixin transformation does not transfer annotations on the method or that spring's component scanner works before the mixin is processed. Either way, is there a groovier way to achieve this functionality (I don't want AController to extend Reporter for other reasons, so that's not an option) ?
You can find below the responses I got from Guillaume Laforge (Groovy project manager) in Groovy users mailing list.
Hi,
I haven't looked at Spring MVC's implementation, but I suspect that
it's using reflection to find the available methods. And "mixin"
adding methods dynamically, it's not something that's visible through
reflection.
We've had problems with #Mixin over the years, and it's implementation
is far from ideal and bug-ridden despite our efforts to fix it. It's
likely we're going to deprecate it soon, and introduce something like
static mixins or traits, which would then add methods "for real" in
the class, which means such methods like doReport() would be seen by a
framework like Spring MVC.
There are a couple initiatives in that area already, like a prototype
branch from Cédric and also something in Grails which does essentially
that (ie. adding "real" methods through an AST transformation).
Although no firm decision has been made there, it's something we'd
like to investigate and provide soon.
Now back to your question, perhaps you could investigate using
#Delegate? You'd add an #Delegate Reporter reporter property in your
controller class. I don't remember if #Delegate carries the
annotation, I haven't double checked, but if it does, that might be a
good solution for you in the short term.
Guillaume
Using the #Delegate transformation did not work on its own, so I needed another suggestion.
One more try... I recalled us speaking about carrying annotations for
delegated methods... and we actually did implement that already. It's
not on by default, so you have to activate it with a parameter for the
#Delegate annotation:
http://groovy.codehaus.org/gapi/groovy/lang/Delegate.html#methodAnnotations
Could you please try with #Delegate(methodAnnotations = true) ?
And the actual solution is:
class Reporter {
#RequestMapping("report")
public String doReport() {
"report"
}
}
#Controller
#RequestMapping("/a")
class AController {
#Delegate(methodAnnotations = true) private Reporter = new Reporter
#RequestMapping("b")
public String doB() {
"b"
}
}
When you map requests with annotations, what happens is that once the container is started, it scans the classpath, looks for annotated classes and methods, and builds the map internally, instead of you manually writing the deployment descriptor.
The scanner reads methods and annotations from the compiled .class files. Maybe Groovy mixins are implemented in such a way that they are resolved at runtime, so the scanner software can't find them in the compiled bytecode.
To solve this problem, you have to find a way to statically mixin code at compile time, so that the annotated method is actually written to the class file.