コントローラーがモデル、ライブラリ、またはヘルパーを呼び出す間、モデルをdbに呼び出すように制限するだけです。 コントローラーとモデルcodeigniterの間のレイヤーの名前付け方法
私はビューのデータを準備するためにロジックをコントローラにもモデルにも入れたくありません。 ビューのすべての配列を準備するロジックは、コントローラで行われます。私はこの部分を分けるためにライブラリを作成していますが、コントローラーがオーバーロードしていると感じることがあります。
したがって、ライブラリークラスを作成し、ビューにデータを作成する前にビューデータを作成します。正確にテンプレート化されているわけではありません。
私はそれをどのように名前を付けるのかわかりません。いい提案ですか？ 私はview_builder、ui_builder、ui_componentsを考えていますか？
乾杯
は、ここで私はアプリをレイヤーしたい方法は次のとおりです。
ビューは、デスクトップまたはブラウザまたはどちらかでありますモバイルベース。
コントローラは表示に密接に拘束されています。モデルオブジェクトへの入力の検証とバインディング、ユースケースを満たすためのサービスの呼び出し、そして次のビューへの応答のルーティングを担当します。
サービスはユースケースを満たします。彼らは仕事の単位、自分のトランザクションについて知り、データベースのようなリソースへの接続を管理します。彼らは、モデルオブジェクト、他のサービス、および永続オブジェクトで動作します。インターフェイスベースのオブジェクトですが、RPC-XML、SOAP、RESTなどのWebサービスとしてリモートまたは公開できます。
永続性は、別のインターフェイスベースのオブジェクトです。実装はリレーショナルまたはNoSQLにすることができます。重要なのは、インターフェイスがモデルオブジェクトのCRUD操作を表現することです。ジェネリックスを使用する場合は、すべてのユーザーに共通のインターフェイスを作成することができます。
私はモデルオブジェクトを持ちません。私は "貧血ドメインモデル"の軽蔑を認識していますが、私はより刺激的な振る舞いがCRUD操作ではなくビジネス目的を中心にすべきだと考えています。
良い設定です。また、CIライブラリを使用して、返されたデータ配列内のキンクをビューに渡す前に、そのキンクを処理することもあります。私は時にはモデルを使うこともあります。
名前について考えてみるといいです。あなたが言及しているものはすべて素晴らしいと思います。ライブラリの名前をdata_structureやarray_to_objectのように指定したり、friend_mapやtag_cloudのような独自の問題に固有のものを考えることもできます。
私のアドバイス：名前を選んで、さらに説明的なものが出てきたり、あなたのライブラリの機能が何かに進化したら、それを変更するのを恐れないでください。 Find + replaceはあなたの友人です。