0

私は単にこの状況に対処するための最善の方法についてのアドバイスを探しています。

現在、Serviceというフォルダにいくつかのファイルがあります。ファイルは、もちろんランダムなことを行ういくつかの関数に接続します。これらの各ファイルは、SMアダプターにアクセスする必要があります。

私の質問は、これらの各ファイルにServiceManagerAwareInterfaceを実装する必要があるのか​​、それともServiceManagerAwareInterfaceを実装する新しいクラスを作成し、このサービスを実装する新しいクラスにクラスを拡張するだけなのかということです。

どちらの方法も正常に機能しますが、どちらの方法がより適切かはわかりません。

4

2 に答える 2

2

システムが常に ZF2 に依存していると思われる場合、どちらのアプローチも同等です。

OO 設計の観点から、個人的には、サービスを拡張してから ServiceManagerAwareInterface を実装するアプローチを好みます。さらに多くのクラスを保護するために、ServiceLocator に対する依存関係にインターフェイスを使用することさえあります。なんで？クラスを拡張しても、インターフェイスに依存するクラスを作成するのと同じように、それほど費用はかかりません。

この例を見てみましょう。ZF1 プロジェクトでこのアプローチを使用しなかったと想像してください。その間、おそらく Zend_Registry で依存関係を解決していました。さて、ZF2 の実装に移行したと仮定しましょう。コードをサービス レイヤーなどZend_Registry::get($serviceX)からリファクタリングするのにどれくらいの時間を費やすと思いますか?$this->getServiceManager()->get($serviceX)

ここで、クラスを保護することを選択したとします。まず、次のように簡単な独自のサービス ロケーター インターフェイスを作成します。

public interface MyOwnServiceLocatorInterface{
    public function get($service);
}

ZF1 では、Zend_Registry を使用してアダプタ クラスを作成しました。

public class MyZF1ServiceLocator implements MyOwnServiceLocatorInterface{
    public function get($service){
        Zend_Registry::get($service);
    }
}

Service クラスは Zend_Registry に結合されていないため、リファクタリングがはるかに簡単になります。

ここで、ZF2 に移行することを決定したので、論理的に を使用しServiceMangerます。次に、この新しい Adapter クラスを作成します。

public class MyZF2ServiceLocator implements 
     ServiceManagerAwareInterface,MyOwnServiceLocatorInterface
{

    private $_sm;

    public function get($service){
        $this->_sm->get($service);
    }

    public function setServiceManager($serviceManager){
         $this->_sm = $serviceManager;
    }
}

繰り返しますが、Service クラスは ZF2 に結合されていませんServiceManger。

さて、ServiceManager でのサービス層の構成/登録はどのように見えるでしょうか。Module::getServiceConfigそのためにクラスを使用します。

//Module.php

public function getServiceConfig()
{
     return array(
           'factories'=>array(
                'My\ServiceA'=>function($sm){
                        return new My\ServiceA($sm->get('My\Service\Name\Space\MyZF2ServiceLocator'));
                    }

            //Some other config

            )
}

ご覧のとおり、インターフェイスに依存し、アダプターを使用してサービス クラスを保護しているため、サービス クラス内でのリファクタリングは必要ありません。クロージャ ファクトリを使用したため、Service クラスを拡張してServiceLocatorAwareInterface.

さて、前の例で結論を出す前に、クラスがファクトリを介して構築されるケースを扱っていないことに注意する必要がありますが、ファクトリのトピックに対処する以前の回答の1つだけでなく、疎結合の重要性も確認できますアプリケーション層の間。

于 2013-01-29T21:04:43.463 に答える
1

そのためにイニシャライザを追加できます。db アダプターを渡すサービスを取得する際の繰り返しの注入を減らすことができます。または、abstract_factories を設定すると、SM 登録の繰り返しが減ります。SMチートシートをここに投稿しました。お役に立てば幸いです:)

https://samsonasik.wordpress.com/2013/01/02/zend-framework-2-cheat-sheet-service-manager/

于 2013-01-29T19:32:55.083 に答える