6

これは多かれ少なかれ過去の Stack Overflow の質問のフレームワーク中心のバージョンであり、 MVC アプリケーションのほとんどの入門資料がモデル、ビュー、およびコントローラー間の密結合をどのように提示する傾向があるかについてのものです。たとえば、フィルター処理されたデータをユーザー ビューにプッシュするユーザー コントローラーによって変更されるユーザー テーブルがあります。多くの MVC フレームワークもこのパターンを反映している傾向があるというのが私の印象です。これはすべて問題ありませんが、HTML フォームを使用して単調なリストを作成して表示する以上のことにはなりません。

現在注目されている MVC フレームワークはLithiumです。これは、巧妙な PHP5.3 コーディング手法のケーススタディとして非常に興味深いものです。Lithium にはModel、個々のテーブルのラッパー オブジェクトを提供し、いくつかの単純なクエリを抽象化するクラスがあります。一方、コントローラー オブジェクトのメソッド呼び出しに URL をルーティングし、それをレンダリングしてテンプレートを表示するという気の利いた規則があります。

しかし、その最中に、テーブル A のデータをテーブル B ～ Z のデータに関連付けるすべての興味深いロジックをどこに配置すればよいか途方にくれています。または、少なくとも、そのような配置場所がわかりません。フレームワークの設計と一致する方法でのロジック。私の理解では、Lithium のModel抽象化は、行レベルの挿入/更新/削除のボイラープレートを排除する以上のことはなく、コントローラー/ビュー アーキテクチャは主にユーザー インターフェイスに関するものです。ControllerURL 要求からルーティングされた関数呼び出しを受け取る同じクラスに、多くのビジネス ロジックを配置したくありません。

私の本能は、多かれ少なかれ完全にフレームワークの外に存在する独自のコードの束でギャップを埋めることです。それ以上のものを期待するべきかどうかはわかりませんが、他のすべてが Lithium でどれほど厳密に構造化されているかを考えると、何か不満を感じます。大きな枠組み。

ここで何が欠けていますか？このタイプのフレームワークを使用するための推奨されるアーキテクチャまたは哲学はありますか?

4

1 に答える 1

8

Lithiumで覚えておかなければならないことの1つは、本番環境でのリリースがまだないことです（ただし、一部のサイトでは本番環境で使用しています）。現在欠けている主な機能はモデルの関係です。関係が整っていれば、より複雑なアプリケーションを作成する全体像の重要な要素であるため、あなたの質問は部分的に答えられると思います。リレーションの作業を継続する必要があるx-dataブランチを確認できます。

ドメインロジックの記述の2番目の部分では、簡単な答えは「モデル内」です。たとえば、モデル機能を拡張するこの（かなり役に立たない）例を参照してください。注目すべきもう1つの例は、使用中のリチウムの数少ない実用的なオープン例の1つであるオープンソースのミニアプリケーションAnalogueです。Analogueモデルクラスは、もう少し肉厚なモデルを示しています。

そして最後に、M、V、Cの間のドットを接続する問題です。リチウムコントローラーは、主にモデルにジョブを委任し、必要に応じて入力データを再構築する必要があります。Postモデル、PostsController、views / posts / add、indexなどを使用する簡単な例は、単にPost :: all（）が含まれている必要があるという意味ではありません。PostsController :: viewは、おそらくコメントモデルのセットをロードする必要があります。

もちろん、そこに独自のコードをたくさん投げます！そうでなければ、それはあまりアプリケーションではないでしょう。ただし、ドメインロジックは、自然なモデルに関連付けておいてください。

  • ブログ投稿に一意のタイトルがあることを確認する必要がありますか？バリデーターを作成します。
  • ユーザーが投稿への書き込みアクセス権を持っていることを確認する必要がありますか？saveメソッドをオーバーライドして検証するか、フィルタリングします。

しかし、Lithiumでの構造化アプリケーションをどのように最適に解決できるかを完全に判断するには、土地との関係と1.0のリリースを待つ必要があると思います。

于 2011-01-12T18:15:02.137 に答える