0

私は独自の PHP MVC フレームワークを作成していますが、たとえばUserのような永続データ オブジェクトをコーディングするのに最も適切な場所はどこか疑問に思っていました。$_SESSION、APC、memcached などの永続ストレージがなければ、だれかが http リクエストごとにデータベースからユーザー データを取得できてしまいます。これは、パフォーマンスの点で悪い考えです。(M)odel は良い選択のようです。このようなものは良いスタートです: 

class UserModel extends Model
{
  public function getEmail()
  {
    $user = Session::get('User');
    if(isset($user))
    {
      return $user->Email;
    }
    return null;
  }
}

ほとんどのモデルが行う db データを返さないため、おそらくそうではありません。独立したクラスを作成する必要がありますか? これには何かパターンがありますか？グローバルにしたくないのですが、そのようなオブジェクトの所有者/管理者は誰ですか?

4

1 に答える 1

2

モデルは、ビジネス ロジックのみをモデル化する必要があります。ユーザーとのやり取りとは何の関係もありません。それがコントローラー (およびビュー) の仕事です。セッションは、まさにユーザー インタラクションの領域にあります。したがって、モデルでは使用しないでください。コマンドラインまたはセッションが存在しない他のコンテキストからモデルを使用することを常に想定してください。これにより、アプリケーションの設計に関する多くの情報が得られるはずです。

さまざまな段階でキャッシュを実装して、プライマリ データ ストアの負荷を軽減できます。アプリのコア ロジックを表すモデル レイヤーまたはサービス レイヤーが必要です。このレイヤーには、アプリで何かを行うために使用する API が定義されています。データベースの負荷を軽減するために、レイヤーが memcache などを使用して一部のデータを内部的にキャッシュする舞台裏である可能性があります。
次に、モデル レイヤーからデータを取得して視覚化するビュー レイヤーが必要です。そのビュー レイヤーは、モデル レイヤーから受け取ったデータをどこかにキャッシュする場合があります。

最大のポイントは、懸念事項を適切に分離することです。N-Tier Architecture - An Introductionを参照してください。さらにアイデアが得られる場合があります。

于 2012-09-03T16:09:12.860 に答える