CodeIgniterアプリケーションでサービスレイヤを実装する正しい方法

Question

以下は、CodeIgniterアプリケーションでサービスレイヤを実装できる2つの方法です。

1方法

1.send request to the controller 
2.calling service layer methods from controller 
3.return processed result data set(D1) from service layer to controller 
4.then according to that data set controller demand data from model 
5.model return data set(D2) to the controller 
6.then controller send second data set(D2) to view. 

---

2方法

1.send request to the controller 
2.calling service layer methods from controller 
3.service layer demand data from model 
4.model send requested data set(d1) to the service layer 
5.after some processing return generated data(d2) to controller from service layer 
6.then controller send data set(d2) to view. 

---

CodeIgniterでサービスレイヤを実装する正しい方法は何ですか？これら2つの方法以外にも、他に良い方法がありますか？

コードで例を挙げることができれば、それはすばらしいことになります。

Answer 1

これは必ずしもそれを行うための正しい方法ではありませんが、私のようなフレームワークは、一般的にそれを行う可能性があります方法を説明するつもりだと、あなたは他の方法について学習し、最良のものを決めることができ、注意してくださいあなたのユースケース。したがって、私はこの答えが正しいとは思っていませんが、話していることを実際に知っている人が一緒に来て（そしてまたその人に - この答えを編集する/自由に下ろす：D）。最後に、これはCodeIgniterとは関係なく、一般的なフレームワークです。あなたの質問は、フレームワークにとらわれず、言語にとらわれないものとして構成されるべきです。

だから私はここに意見を提供するつもりだ、それは特にPHP、内のすべての近代的なフレームワークは、MVCをしないという事実です。何でこれが大切ですか？私たちは皆同じ言語を話す必要があり、 'mvc'はPHPには存在しないからです。あれは事実です。それを受け入れると、フレームワークが使用するコンセプトの荒廃に進むことができます。 CodeIgnitorは 'MVC'の悪用の特に大きな例です。以後、引用符付きの "mvc"と呼ばれます。

プラス側はsymfonyのようなフレームワークは、例えば、少なくともアプリケーション間の一貫性のいくつかのフォームが含まれている最初の独断アーキテクチャを提供することであり、それはこのような何かを行く：

1. 標準のHTTPあなたが開発中であるかプロダクション中であるかに応じて、要求がフロントコントローラーに到着し、通常app.phpまたはapp_dev.phpになります。 1つは、各変更で実行する必要があるキャッシュの多くを含み、もう1つは開発には完璧です。

2. ルータは現在のURLをコントローラクラスと照合し、そのクラス内の「アクション」（メソッド）を照合します。

3. フレームワークの依存性注入部分は、コントローラーからモデルレイヤーまでのすべてのオブジェクトに必要なオブジェクトを特定し、必要に応じてそれらをインスタンス化するか、インスタンス化する準備を行います。

4. コントローラーは、必要な依存関係でインスタンス化され、関連するメソッドが実行されます。これは通常、開発を開始し、フレームワークに「コードをフック」する場所です。

5. これはあなたのアーキテクチャを決定するところですが、開発者の観点とビジネスの観点からの最も重要な点は、整合性です。

6. 自分のコードがフレームワークから切り離されているようにすることを個人的に好みます。私は、要求から取得したスカラーを、モデルレイヤー（DIを介して渡されたオブジェクト）を使用してドメインオブジェクトを使用するアプリケーションレイヤーサービスに渡します。ここでのポイントは、ドメインオブジェクトがコントローラに直接渡されるのではなく、アプリケーションレイヤの媒体を介してプロキシされるため、理論的にはこれを取り囲むフレームワーク全体を置き換えることができます。それらがモデルレイヤーに達する前に、それはすべて動作します（CLIコール、それ以上のコントローラーを考える）。

アプリケーションレベルのサービスは、任意の Repositories、 Servicesなどを必要に応じ使用

7. （およびそれらにそれらのスカラーを渡し、分離を覚えている？）、ビジネス・ロジックを実行している、（一般的にこれらは、あなたのデザインパターンは、日に出番日単位）、そのデータをアプリケーションレベルのサービスに戻すことができます。

8. サービスはコントローラにデータを返し、何を推測しますか？これは、フレームワークがめちゃくちゃになる傾向がある場所です！今日のフレームワークでは「ビュー」の概念がないためです。テンプレートは1つしかありません。そのデータをテンプレートに渡して、それをテンプレートにします。だからあなたの図では、それは物事の仕方ではないので、ビューの概念は全くありません。そして、まったく正直なところ、私はまだテンプレートを使用しています。なぜなら、これは最速の方法ですから、現代​​のフレームワークが一緒になって実際にViewsを使い始めるまでは、運が悪いので、 Laravelのような一部の人が "mvc"フレームワークとして自分自身を参照しているという事実です。

注意、ファビアンPotencierは、明示的にsymfonyはMVCフレームワークではなかったと述べている - 少なくとも、彼は彼がそこに話して知っています。繰り返しますが、これはではなく、純粋主義者です。私たちは皆同じことを言っています。実際にはの言語をコンピューティングで使用しています。

だから、

、図のようにあなたはそんなに、ここ

これは、それぞれのReviewとCriteriaの概念を持つアプリケーションのためです...いくつかは、今日のフレームワークでそれを行う可能性がある方法ですので、 Review。 Symfonyのフォームから始めることさえできません。彼らはあらゆるアーキテクチャーの深刻な部分ではないすべてのものに結びついています。

いくつのエフェクトレイヤーが必要ですか？私たちはすでに「MVC」を持っています.DDDには、「アプリケーション」、「ドメイン」、「インフラストラクチャ」の分離という概念があります。あなたは本当に別のレイヤーが必要ですか、それとも十分でしょうか？考えるべき事...

を参照してください、あなたはこの分離の結果として起こったアプリケーションを取得するためのフレームワーク/ HTTPリクエストで立ち往生していません。

上記の図の「サービス」を参照してください。それらはコントローラから分離されているので、どこからでもスカラを投げることができ、アプリケーションは引き続き動作します。 これはあなたに必要な分離を与えると思う。正しいやり方を学び、それをやる方法を学んだり、自分自身をコントロールしたり、ビジネスやそれに必要なことについて実践的に学ぶ方法を学ぶのは素晴らしいことですが、フレームワークは自分のものを並べ替える必要があります。 CodeIgniterで素敵なコードを書いてください;）

Answer 2

最初に使用する必要があります。 MVC Webアプリケーションでは、コントローラを使用してビジネスロジックをビューから分離するので、それはゲートウェイのようなものです。コントローラーを使用して情報を処理する必要があります。コントローラーから、モデルまたはサービスレイヤーまたは必要なものを呼び出す必要があります。&最後に、ここから他のソースにデータを戻す必要があります。ビューまたはサービスレイヤーはモデルに直接アクセスすべきではありません。

Answer 3

私見は間違ってここには右または存在しません：

オプション＃1 - あなたは複数のコントローラ/アクション におけるサービスレイヤを再使用に基づいて異なるモデルからのデータをその送りたい場合それは最初のものに行くのが理にかなっています。

オプション2＃ - ただし、データモデルが複雑な場合は、最初のオプションが問題になることがあります。最初の呼び出しのデータに基づいてモデルへの2番目の呼び出しが必要な場合はどうなりますか？このビジネスロジックにコントローラを使用すると、サービスレイヤの目的がすべて失われます。この場合、2番目のものに行く方が良いかもしれません。

私は、第2のものがより一般的なものだと思います。

Answer 4

依存性注入とアダプタパターンは、開始するのに適しています。 CodeIgniterサポートはそのままではないので、ラッパーまたはフックを記述する必要があります。

jsonが.jsonファイルにプリレンダリングされて出力として返される必要があるため、ビューではxml | htmlしかサポートできませんでしたが、コードで行う必要があります。フロントエンドで変更されました。 PHPは（xml | html）で動作する組み込み言語です

サービスモデルは、コントローラ/モデルに を注入（依存性注入）したときに最もよく機能し、そのコントローラ/モデルのプロパティとしてリストされます。

サービスは、それらの両方は、要求と応答機能を有するが、両方が同様のパターンに従って、未だ異なるエンドポイントを有する例示のFacebook /さえずり ためのインターフェース

に結合されます。ここで

を必要

interface SocialMediaAdapter{ 
    public request(url); 
    public response(); 
} 

---

public class FaceBookProvider implements SocialMediaAdapter 
{ 
    public request(url){ 

    } 
    public response(){ 

    } 

}

public class TwitterProvider implements SocialMediaAdapter 
    { 
     public request(url){ 

     } 
     public response(){ 

     } 
    } 

---

public class SocialMediaServiceProvider{ 

    protected $provider = null; 

    public function constructor(SocialMediaAdapter $provider){ 
     $this->provider = $provider; 
    } 

    public function fetch($url){ 
     return $this->provider->request($url); 
    } 
} 

依存性注入