douzheng5717 2014-10-06 18:23
浏览 94
已采纳

我应该在开发业务代码时使用IoC依赖注入吗?

Modern PHP frameworks (like Zend, Symfony, Phalcon) all use a DI container and you simply pass it around to access all the framework functionalities. I'm wondering if I should/could use the DI container in my business code. Let's say I need to use a database access object and a mailer object and they are already in the DI because the framework use them. Could I simply pass the DI container when instantiating a business class?

For example, I have a class that deals with users in the database, you could call it my user model class. Right now I simply pass the DI container to the constructor of the model class when instantiating it in a controller and it's fine and easy. Just toss everything in the DI container and done.

But I'm about to develop an API that will also use this user model class. Since it expects a DI container, I would need to know before hand what the dependencies of the model are and initialize a DI container with the right ones. Before, I would just pass each dependency as a parameter in the constructor but with IoC I need to know, without looking at the parameters, what are the dependencies of the class and what is the name used to access each dependency. For instance, I would need to know that there should be a PDO object identified by 'db' in the DI container. Is this a good approach for business/library code?

I'm probably mixing up terms here but I hope you get the idea.

Thanks!

  • 写回答

1条回答 默认 最新

  • draw62188 2014-10-06 22:03
    关注

    It doesn't really matter what kind of code you are developing, be it business logic or framework logic (or another kind of logic), the entire point here is how you deal with class dependencies.

    The term business logic itself is very abstractive. You can represent a business logic with a single class (a.k.a domain object) or you can represent a business logic as a layer.

    One basic thing to note: Database is just a storage engine

    When you develop any application, you should keep in mind that database can be changed (or you could migrate to NoSQL solution in the future). And when/if you do, then $pdo is no longer a dependency. If you had storage logic totally decoupled from business one, then it will be easy enough to replace a storage engine. Otherwise you end up rewriting a lot of things when changing it.

    A properly designed architecture encourages to decouple storage logic from application logic. Those patterns are established as a best practice: Data Mapper or Table Gateway

    namespace Storage\MySQL;
    
    use PDO;
    
    abstract class AbstractMapper
    {
         protected $pdo;
    
         public function __construct(PDO $pdo)
         {
                $this->pdo = $pdo;
         }
    }
    
    class UserMapper extends AbstractMapper
    {
        private $table = 'cms_users';
    
        public function fetchById($id)
        {
           $query = sprintf('SELECT * FROM `%s` WHERE `id` =:id', $this->table);
           $stmt = $this->pdo->prepare($query);
           $stmt->execute(array(
               ':id' => $id
           ));
    
           return $stmt->fetch();
        }
    
        // the rest methods that abstract table queries
    }
    

    So in this case, for the current storage engine $pdo is a core dependency and it's not a dependency of a framework or the application you're developing. The next problem you should solve here is how to automatize this process of passing $pdo dependency to mappers. There's only one solution you can take advantage of - Factory pattern

    $pdo = new PDO();
    $mapperFactory = new App\Storage\MySQL\Factory($pdo);
    
    $mapperFactory->build('UserMapper'); // will return UserMapper instance with injected $pdo dependency
    

    Now let's see obvious benefits:

    First of all, it's readability - anyone seeing the code will get the clue, that Mapper is being used to abstract table access. Second you can easily replace a storage engine (if you plan to migrate in future and add several databases support)

    $mongo = new Mongo();
    $mapperFactory = new App\Storage\Mongo\Factory($mongo);
    
    $mapperFactory->build('UserMapper'); // will return UserMapper instance with injected $mongo dependency
    

    Note: All mappers for different storage engines should implement one interface (API enforcement)

    Model should not be one class

    When it comes to web, we basically do the following:

    • Rendering a form (that might look like Contact Page, Login form etc)
    • Then submitting a form
    • Then comparing against our validation rules
    • On success we insert form data into a storage engine, on failure we display error messages

    So when you implement a model as a class, then you end up writing validation and storage logic in the same class, therefore tight-coupling and breaking the SRP.

    One of this common example, you can see in Yii Framework

    A proper model should be a folder of classes containing application logic (see in ZF2 or SF2).

    And finally, should you really use DiC?

    Should you use a DI container when developing a code? Well, let's look at this classical code example:

    class House
    {
          public function __construct($diContainer)
          {
                 //Let's assume that door and window have their own dependencies
                 // So no, it's not a Service Locator in this case
                 $this->door = $diContainer->getDoor();
                 $this->window = $diContainer->getWindow();
                 $this->floor = $diContainer->getFloor();
          }
    }
    
    $house = new House($di)
    

    In this case you tell that your House depends on DiC and not explicitly on doors, window and floor. But wait does our House really depend on DiC? Surely it doesn't.

    And when you start testing your class, you would have also to provide a prepared DiC (which is completely irrelevant)

    Usually people use Di containers in order to avoid injection all the time. But from another side, it costs some RAM and some time to parse since most DI containers are configuration based.

    Good architecture can be free of any Di container, since it takes advantage of Factories and the SRP.

    So good application components should be free of any Service Locators and Di Containers.

    本回答被题主选为最佳回答 , 对您是否有帮助呢?
    评论

报告相同问题?

悬赏问题

  • ¥20 ML307A在使用AT命令连接EMQX平台的MQTT时被拒绝
  • ¥20 腾讯企业邮箱邮件可以恢复么
  • ¥15 有人知道怎么将自己的迁移策略布到edgecloudsim上使用吗?
  • ¥15 错误 LNK2001 无法解析的外部符号
  • ¥50 安装pyaudiokits失败
  • ¥15 计组这些题应该咋做呀
  • ¥60 更换迈创SOL6M4AE卡的时候,驱动要重新装才能使用,怎么解决?
  • ¥15 让node服务器有自动加载文件的功能
  • ¥15 jmeter脚本回放有的是对的有的是错的
  • ¥15 r语言蛋白组学相关问题