3

一部の機能をサービス層に移動する必要があることに気付きました。この特定のケースでは、zend-paginator に関する例に関連しています。

この例では、サービス レイヤーはコントローラーとモデルの間の単なる中間段階です。これは意図された役割のようであり、特定の状況下では理にかなっているようです。

しかし、それは私にいくつかの疑問を投げかけます。

まず、サービス コードの例を簡単にコントローラーに移すことはできませんか?コードのレイヤーを削除してもメリットはありませんか?

コードをサービス レイヤーに移動することで具体的なメリットがあると仮定すると、残りのマッパー インタラクションはどうなるでしょうか。コントローラーは一部のタスクではサービス レイヤーにアクセスし、他のタスクではマッパーにアクセスしますか? それとも、サービス レイヤーがすべてのマッパー インタラクションのプロキシになりますか?

フォームから新しい行を作成するなどの場合、サービス層は値を追加しないため、文字通りサービス層レベルでのパススルー関数になります。

一部のタスクに使用すると、後で複雑になるように思われますが、プロキシとして使用すると、意図的にコードの複製と複雑さを導入しているように見えます。

「ベストプラクティス」に関する説明は非常に役立ちます。

4

1 に答える 1

1

コードをコントローラーに移動すると、コントローラーが太くなります。アプリケーションとUIを緊密に結合します。別のコンテキストでそのアクションを実行することは困難になります。スキニーコントローラーは、1つ以上のサービスを使用して応答を生成することにより、特定のコンテキストで要求を処理します。

これらのサービスは、さまざまなコンテキストに統合できる疎結合の方法でモデルと対話することにより、アプリケーションの境界(ドメインロジック)を定義します。

たとえば、コントローラーはMVCアプリのサービスレイヤーと対話します。コンソールラッパーは、CLIのサービスレイヤーと対話できます。SOAPまたはJSON-RPCサーバーは、リフレクションを使用してサービスをWebサービスAPIとして公開できます。これはすべて、コードを複製せずに実行できます。

于 2012-04-17T08:26:10.793 に答える