Sf2:在实体内使用服务

Question

我知道这已被一遍又一遍地问过,我读了主题,但它总是专注于特定的情况,我通常试图理解为什么在实体中使用服务不是最好的做法.

给定一个非常简单的服务:

Class Age
{
  private $date1;
  private $date2;
  private $format;

  const ym = "%y years and %m month"
  const ...


  // some DateTime()->diff() methods, checking, formating the entry formats, returning different period formats for eg.
  }

和一个简单的实体:

Class People
{
  private $firstname;
  private $lastname;
  private $birthday;

  }

从控制器,我想做:

$som1 = new People('Paul', 'Smith', '1970-01-01');
$som1->getAge();

当然,我可以重写getAge()我的实体内部的功能,它不长,但我非常懒,因为我已经写了所有可能的datetime-> diff()我需要在上面的服务,我不明白为什么我不应该使用' EM ...

注意:我的问题不是关于如何在我的实体中注入容器,我可以理解为什么这没有意义,但更多的是避免在不同实​​体中重写相同功能的最佳实践.

继承似乎是一个糟糕的"好主意",因为我可以在类BlogArticle中使用getAge(),我怀疑这个BlogArticle类应该继承与People类相同的类...

希望我很清楚,但不确定......

Answer 1

One major confusion for many coders is to think that doctrine entities "are" the model. That is a mistake.

Injecting services into your doctrine entities is a symptom of "trying to do more things than storing data" into your entities. When you see that "anti-pattern" most probably you are violating the "Single Responsability" principle in SOLID programming.

• http://en.wikipedia.org/wiki/Anti-pattern
• http://en.wikipedia.org/wiki/SOLID_%28object-oriented_design%29
• http://en.wikipedia.org/wiki/Single_responsibility_principle )

Symfony is not an MVC framework, it is a VC framework only. Lacks the M part. Doctrine entities (I'll call them entities from now on, see clarification at the end) are a "data persistence layer", not a "model layer". SF has lots of things for views, web controllers, command controllers... but has no help for domain modelling ( http://en.wikipedia.org/wiki/Domain_model ) - even the persistence layer is Doctrine, not Symfony.

Overcoming the problem in SF2

When you "need" services in a data-layer, trigger an antipattern alert. Storage should be only a "put here - get from there" system. Nothing else.

To overcome this problem, you should inject the services into a "logic layer" (Model) and separate it from "pure storage" (data-persistence layer). Following the single responsibility principle, put the logics in one side, put the getters and setters to mysql in another.

The solution is to create the missing Model layer, not present in Symfony2, and make it to give "the logic" of the domain objects, completely separated and decoupled from the layer of data-persistence which knows "how to store" the model into a mysql database with doctrine, or to a redis, or simply to a text file.

所有这些存储系统都应该是可以互换的,你Model应该仍然暴露相同的公共方法,而消费者绝对没有变化.

这是你如何做到的:

第1步:将模型与数据持久性分开

为此,在您的包中,您可以创建另一个以Modelbundle-root级别命名的目录(此外tests,DependencyInjection等等),就像在这个游戏示例中一样.

• 该名称Model不是强制性的,Symfony对此没有任何说明.你可以选择你想要的任何东西.
• 如果您的项目很简单(例如一个包),则可以在同一个包中创建该目录.
• 如果你的项目有很多捆绑,你可以考虑
  • 将模型拆分为不同的包,或者
  • or -as in the example image- use a ModelBundle that contains all the "objects" the project needs (no interfaces, no controllers, no commands, just the logic of the game, and its tests). In the example, you see a ModelBundle, providing logical concepts like Board, Piece or Tile among many others, structures in directories for clarity.

Particularly for your question

In your example, you could have:

Entity/People.php
Model/People.php

• Anything related to "store" should go inside Entity/People.php - Ex: suppose you want to store the birthdate both in a date-time field, as well as in three redundant fields: year, month, day, because of any tricky things related to search or indexing, that are not domain-related (ie not related withe lo 'logics' of a person).
• Anything related to the "logics" should go inside Model/People.php - Ex: how to calculate if a person is over the majority of age just now, given a certain birthdate and the country he lives (which will determine the minumum age). As you can see, this has nothing to do on the persistence.

Step 2: Use factories

Then, you must remember that the consumers of the model, should never ever create model objects using "new". They should use a factory instead, that will setup the model objects properly (will bind to the proper data-storage layer). The only exception is in unit-testing (we'll see it later). But apart from unitary tests, grab this with fire in your brain, and tattoo it with a laser in your retina: Never do a 'new' in a controller or a command. Use the factories instead ;)

为此,您需要创建一个充当模型"getter"的服务.您可以将getter创建为可通过服务访问的工厂.看图像:

你可以在那里看到BoardManager.php.这是工厂.它是与电路板相关的主要吸气剂.在这种情况下,BoardManager具有以下方法:

public function createBoardFromScratch( $width, $height )
public function loadBoardFromJson( $document )
public function loadBoardFromTemplate( $boardTemplate )
public function cloneBoard( $referenceBoard )

• 然后,正如您在图像中看到的那样,在services.yml中定义了该管理器,并将持久层注入其中.在这种情况下,你注入ObjectStorageManager了BoardManager.的ObjectStorageManager是,对于该示例,能够从数据库或从文件存储和加载对象; 而BoardManager存储不可知.
• 你也可以ObjectStorageManager在图像中看到,然后注入@doctrine以便能够访问mysql.
• Your managers are the only place where a new is allowed. Never in a controller or command.

Particularly for your question

In your example, you would have a PeopleManager in the model, able to get the people objects as you need.

Also in the Model, you should use the proper singular-plural names, as this is decoupled from your data-persistence layer. Seems you are currently using People to represent a single Person - this can be because you are currently (wrongly) matching the model to the database table name.

So, involved model classes will be:

PeopleManager -> the factory
People -> A collection of persons.
Person -> A single person.

For example (pseudocode! using C++ notation to indicate the return type):

PeopleManager
{
    // Examples of getting single objects:
    Person getPersonById( $personId ); -> Load it from somewhere (mysql, redis, mongo, file...)
    Person ClonePerson( $referencePerson ); -> Maybe you need or not, depending on the nature the your problem that your program solves.
    Person CreatePersonFromScratch( $name, $lastName, $birthDate ); -> returns a properly initialized person.

    // Examples of getting collections of objects:
    People getPeopleByTown( $townId ); -> returns a collection of people that lives in the given town.
}

People implements ArrayObject
{
    // You could overload assignment, so you can throw an exception if any non-person object is added, so you can always rely on that People contains only Person objects.
}

Person
{
    private $firstname;
    private $lastname;
    private $birthday;
}

So, continuing with your example, when you do...

// **Never ever** do a new from a controller!!!
$som1 = new People('Paul', 'Smith', '1970-01-01');
$som1->getAge();

...you now can mutate to:

// Use factory services instead:
$peopleManager = $this->get( 'myproject.people.manager' );
$som1 = $peopleManager->createPersonFromScratch( 'Paul', 'Smith', '1970-01-01' );
$som1->getAge();

The PeopleManager will do the newfor you.

At this point, your variable $som1 of type Person, as it was created by the factory, can be pre-populated with the necessary mechanics to store and save to the persistence layer.

The myproject.people.manager will be defined in your services.yml and will have access to the doctrine either directly, either via a 'myproject.persistence.manager` layer or whatever.

Note: This injection of the persistence layer via the manager, has several side effects, that would side track from "how to make the model have access to services". See steps 4 and 5 for that.

Step 3: Inject the services you need via the factory.

Now you can inject any services you need into the people.manager

You, if your model object needs to access that service, you have now 2 choices:

• When the factory creates a model object, (ie when PeopleManager creates a Person) to inject it via either the constructor, either a setter.
• Proxy the function in the PeopleManager and inject the PeopleManager thru the constructor or a setter.

In this example, we provide the PeopleManager with the service to be consumed by the model. When the people manager is requested a new model object, it injects the service needed to it in the new sentence, so the model object can access the external service directly.

// Example of injecting the low-level service.
class PeopleManager
{
    private $externalService = null;

    class PeopleManager( ServiceType $externalService )
    {
        $this->externalService = $externalService;
    }

    public function CreatePersonFromScratch()
    {
        $externalService = $this->externalService;
        $p = new Person( $externalService );
    }
}

class Person
{
    private $externalService = null;

    class Person( ServiceType $externalService )
    {
        $this->externalService = $externalService;
    }

    public function ConsumeTheService()
    {
        $this->externalService->nativeCall();  // Use the external API.
    }
}

// Using it.
$peopleManager = $this->get( 'myproject.people.manager' );
$person = $peopleManager->createPersonFromScratch();
$person->consumeTheService()

In this example, we provide the PeopleManager with the service to be consumed by the model. Nevertheless, when the people manager is requested a new model object, it injects itself to the object created, so the model object can access the external service via the manager, which then hides the API, so if ever the external service changes the API, the manager can do the proper conversions for all the consumers in the model.

// Second example. Using the manager as a proxy.
class PeopleManager
{
    private $externalService = null;

    class PeopleManager( ServiceType $externalService )
    {
        $this->externalService = $externalService;
    }

    public function createPersonFromScratch()
    {
        $externalService = $this->externalService;
        $p = new Person( $externalService);
    }

    public function wrapperCall()
    {
         return $this->externalService->nativeCall();
    }
}

class Person
{
    private $peopleManager = null;

    class Person( PeopleManager $peopleManager )
    {
        $this->peopleManager = $peopleManager ;
    }

    public function ConsumeTheService()
    {
        $this->peopleManager->wrapperCall(); // Use the manager to call the external API.
    }
}

// Using it.
$peopleManager = $this->get( 'myproject.people.manager' );
$person = $peopleManager->createPersonFromScratch();
$person->ConsumeTheService()

Step 4: Throw events for everything

At this point, you can use any service in any model. Seems all is done.

Nevertheless, when you implement it, you will find problems at decoupling the model with the entity, if you want a truly SOLID pattern. This also applies to decoupling this model from other parts of the model.

The problem clearly arises at places like "when to do a flush()" or "when to decide if something must be saved or left to be saved later" (specially in long-living PHP processes), as well as the problematic changes in case the doctrine changes its API and things like this.

But is also true when you want to test a Person without testing its House, but the House must "monitor" if the Person changes its name to change the name in the mailbox. This is specially try for long-living processes.

The solution to this is to use the observer pattern ( http://en.wikipedia.org/wiki/Observer_pattern ) so your model objects throw events nearly for anything and an observer decides to cache data to RAM, to fill data or to store data to the disk.

This strongly enhances the solid/closed principle. You should never change your model if the thing you change is not domain-related. For example adding a new way of storing to a new type of database, should require zero edition on your model classes.

You can see an example of this in the following image. In it, I highlight a bundle named "TurnBasedBundle" that is like the core functionality for every game that is turn-based, despite if it has a board or not. You can see that the bundle only has Model and Tests.

Every game has a ruleset, players, and during the game, the players express the desires of what they want to do.

In the Game object, the instantiators will add the ruleset (poker? chess? tic-tac-toe?). Caution: what if the ruleset I want to load does not exist?

When initializing, someone (maybe the /start controller) will add players. Caution: what if the game is 2-players and I add three?

And during the game the controller that receives the players movements will add desires (for example, if playing chess, "the player wants to move queen to this tile" -which may be a valid, or not-.

In the picture you can see those 3 actions under control thanks to the events.

• You can observe that the bundle has only Model and Tests.
• In the model, we define our 2 objects: Game, and the GameManager, to get instances of Game objects.
• We also define Interfaces, like for example the GameObserver, so anyone willing to receive the Game events should be a GameObserver folk.

• Then you can see that for any action that modifies the state of the model (for example adding a player), I have 2 events: PRE and POST. See how it works:

  1. Someone calls the $game->addPlayer( $player ) method.
  2. As soon as we enter the addPlayer() function, the PRE event is raised.
  3. The observers then can catch this event to decide if a player can be added or not.
  4. All PRE events should come with a cancel passed by reference. So if someone decides this is a game for 2 players and you try to add a 3rd one, the $cancel will be set to true.
  5. Then you are again inside the addPlayer function. You can check if someone wanted to cancel the operation.
  6. Do the operation if allowed (ie: mutate the $this-> state).
  7. After the state has been changed, raise a POST event to indicate the observers that the operation has been completed.

In the picture you see three, but of course it has a lot lot more. As a rule of thumb, you will have nearly 2 events per setter, 2 events per method that can modify the state of the model and 1 event for each "unavoidable" action. So if you have 10 methods on a class that operate on it, you can expect to have about 15 or 20 events.

You can easily see this in the typical simple text box of any graphyc library of any operating system: Typical events will be: gotFocus, lostFocus, keyPress, keyDown, keyUp, mouseDown, mouseMove, etc...

Particularly, in your example

The Person will have something like preChangeAge, postChangeAge, preChangeName, postChangeName, preChangeLastName, postChangeLastName, in case you have setters for each of them.

For long-living actions like "person, do walk for 10 seconds" you maybe have 3: preStartWalking, postStartWalking, postStopWalking (in case a stop of 10 seconds cannot be programatically prevented).

If you want to simplify, you can have two single preChanged( $what, & $cancel ) and postChanged( $what ) events for everything.

If you never prevent your changes to happen, you can even just have one single event changed() for all and any change to your model. Then your entity will just "copy" the model properties in the entity properties at every change. This is OK for simple classes and projects or for structures you are not going to publish for third-party consumers, and saves some coding. If the model class becomes a core class to your project, spending a bit of time adding all the events list will save you time in the future.

Step 5: Catch the events from the data layer.

It is at this point that your data-layer bundle enters in action!!!

Make your data layer an observer of your model. When the model Changes its internal state then make your Entity to "copy" that state into the entity state.

In this case, the MVC acts as expected: The Controller, operates on the Model. The consequences of this are still hidden from the controller (as the controller should not have access to Doctrine). The model "broadcasts" the operation made, so anyone interested knows, which in turn triggers that the data-layer knows about the model change.

Particularly, in your project

The Model/Person object will have been created by the PeopleManager. When creating it, the PeopleManager, which is a service, and therefore can have other services injected, can have the ObjectStorageManager subsystem handy. So the PeopleManager can get the Entity/People that you reference in your question and add the Entity/People as an observer to Model/Person.

In the Entity/People mainly you substitute all the setters by event catchers.

You read your code like this: When the Model/Person changes its LastName, the Entity/People will be notified and will copy the data into its internal structure.

Most probably, you are tempted to inject the entity inside the model, so instead of throwing an event, you call the setters of the Entity.

But with that approach, you 'break' the Open-Closed principle. So if at any given point you want to migrate to MongoDb, you need to "change" your "entities" by "documents" in your model. With the observer-pattern, this change occurs outside the model, who never knows the nature of the observer beyond that is its a PersonObserver.

Step 6: Unit test everything

Finally, you want to unit test your software. As this pattern I have explained overcomes the anti-pattern that you discovered, you can (and you should) unit-test the logics of your model independently of how that is stored.

Following this pattern, helps you to go towards the SOLID principles, so each "unit of code" is independent on the others. This will allow you to create unit-tests that will test the "logics" of your Model without writing to the database, as it will inject a fake data-storage layer as a test-double.

Let me use the game example again. I show you in the image the Game test. Assume all games can last several days and the starting datetime is stored in the database. We in the example currently test only if getStartDate() returns a dateTime object.

There are some arrows in it, that represent the flow.

In this example, from the two injecting strategies I told you, I choose the first one: To inject into the Game model object the services it needs (in this case a BoardManager, PieceManager and ObjectStorageManager) and not to inject the GameManager itself.

1. First, you invoke phpunit that will call look for the Tests directory, recursively in all the directories, finding classes named XxxTest. Then will desire to invoke all the methods named textSomething().
2. But before calling it, for each test method it calls the setup().
3. In the setup we will create some test-doubles to avoid "real access" to the database when testing, while correctly testing the logics in our model. In this case a double of my own data layer manager, ObjectStorageManager.
4. It is assigned to a temporary variable for clarity...
5. ...that is stored in the GameTest instance...
6. ...for later use in the test itself.
7. The $sut (system under test) variable is then created with a new command, not via a manager. Do you remember that I said that tests were an exception? If you use the manager (you still can) here it is not a unit-test, it's an integration test because tests two classes: the manager and the game. In the new command we fake all the dependencies that the model has (like a board manager, and like a piece manager). I am hardcoding GameId = 1 here. This relates to data-persistance, see below.
8. We then may call the system under test (a simple Game model object) to test its internals.

I am hardcoding "Game id = 1" in the new. In this case we are only testing that the returned type is a DateTime object. But in case we want to test also that the date that it gets is the proper one, we can "tune" the ObjectStorageManager (data-persistance layer) mock to return whatever we want in the internal call, so we could test that for example when I request the date to the data-layer for game=1 the date is 1st-jun-2014 and for game=2 the date is 2nd-jun-2014. Then in the testGetStartDate I would create 2 new instances, with Ids 1 and 2 and check the content of the result.

Particularly, in your project

You will have a Test/Model/PersonTest unit test that will be able to play with the logics of the person, and in case of needing a person from the database, you will fake it thru the mock.

In case you want to test the storing of the person to the database, it is enough that you unit-test that the event is thrown, no matter who listens to it. You can create a fake listener, attach to the event, and when the postChangeAge happens mark a flag and do nothing (no real database storage). Then you assert that the flag is set.

In short:

1. Do not confuse logics and data-persistance. Create a Model that has nothing to do with entities, and put all the logics in it.
2. Do never use new to get your models from any consumer. U