ZendFramework2の新しいEventmanagerを使用しようとしています。基本的な使用法を理解しています。しかし、これを実際のプロジェクトでどのように使用するか、あるいはコードをどこに配置するかはわかりません。
例：Rob Allen（上記のリンク）からの紹介で、彼は「findById」メソッドで2つのイベントをトリガーします。リスナーのコードはどこに行くべきですか？私の意見では、このコードをPhotoMapperクラスにも入れるのは意味がありませんか、それとも間違っていますか？
1 に答える
0
私はまだそれを強く試していないと告白しますが、リスナーコードはおそらくマッパーに含まれるべきではないというのは正しいと思います。むしろ、外部クラスでスタンドアロンにすることができるため、実際には単一責任オブジェクト（サブスクライブするイベントを処理する）にすることができ、コードは可能な限りDRYのままにすることができます。
最初のステップとして、リスナーが自分の仕事をするために必要なものを定義できます。インスタンス化について彼が知っていることもあれば、イベントがトリガーされたときに合格する必要があることもあります。
たとえば、キャッシュリスナーの場合、ブートストラップで、キャッシュする場所や存続期間などの情報を使用してインスタンス化することができます。おそらく、完全に構成され、cachemanagerリソースから移動する準備ができているキャッシュインスタンスを取得することもできます。これらは、リスナーオブジェクトのコンストラクターパラメーターである可能性があります。
次に、おそらくBootstrapで、このリスナーをイベントマネージャーに登録し、イベントをサブスクライブし、イベントがトリガーされたときに実行するメソッドをアタッチします。もちろん、そのメソッドシグネチャは、イベントマネージャから提供される情報と互換性がある必要があります。
このリスナーオブジェクトには、次のような潜在的な利点があると思います。
単一の責任であるため、複雑さが低く、テストが容易です
うまくいけば、この単一のリスナーが複数のイベントを処理できるように、十分に一般的です。
ここに少しシワがあります。あるダウンストリームプロセスが、彼がサブスクライブしているイベントをトリガーする可能性があるという偶然に、リスナーをインスタンス化して登録することは、不合理なパフォーマンスヒットのように見えるかもしれません。そこで静的リスナーが登場します。ここでも、登録は（Bootstrapのように）早期に行われますが、リスナーは本当に必要になるまでインスタンス化されません。
開示：私はこれを完全に間違っているかもしれません。ですから、誰かが私をまっすぐにしたいのなら、それは素晴らしいことです。;-)
于 2012-06-24T05:22:20.493 に答える