0

両方持っていることに意味はありますか？ユーザーモデルを作成するように指示されたZendチュートリアルに従いましたが、DBモデルクラスでユーザーをモデル化することはできませんか？

ありがとう

4

2 に答える 2

2

これは、「関心の分離」の概念の一部です。http://en.wikipedia.org/wiki/Separation_of_concerns

モデルクラスはビジネスロジック、検証、変数操作などを処理し、dbモデルクラスはデータベースの処理を処理する必要があります。そうすれば、dbモデルを置き換える必要がある場合でも、メインモデルにそれほど影響を与えることはありません。メインモデルは、適切なパラメータが渡されている限り、dbモデルに影響を与えません。

于 2012-08-22T12:42:49.667 に答える
0

はい、Application_Model_DbTable_User（DbTableクラス）でユーザーをモデル化できます。必要なすべてのデータがその1つのテーブルにある限り、正常に機能します。

ある時点で、複数のテーブルで表現する必要のあるオブジェクトの操作を開始する可能性があります。これは、物事を行うための別の方法の必要性を発見するときです。

マッパーとドメインオブジェクトが重要になる可能性のある場所のより簡単な例：

mp3ファイル。
最も単純な場合、単一の音楽ファイルは、おそらく少なくとも3つのdbテーブルで表される必要があります。

  1. アルバム：曲の元のアルバムを表すテーブル
  2. アーティスト：曲を録音したアーティスト
  3. トラック：トラック自体に関する情報

各アーティストは複数のアルバムを持つことができ、各アルバムには1つのアーティストがあり、複数のトラックがあります。各トラックは1つのアルバムと1つのアーティストに属します（バージョンが異なればトラックも異なります）。

ご覧のとおり、単純なmp3コレクションのデータベース構造でさえ非常にすぐに複雑になる可能性があります。ほとんどの場合、保持されているデータの量と種類に応じて、単純なユーザーレコードでさえ複数のテーブルに分散します。

マッパーとモデルを実装する方法と理由を理解するための助けとして、これらのリソースが非常に役立つことがわかりました。

ドメインモデルの構築では、ドメインモデルとは何か、およびPHPでドメインモデルを構築する方法について説明します。
マッパーをドメインモデルに追加すると、同じドメインモデルにマッパー関数が追加されます。モデルとテストに焦点を当てたZendFrameworkスターターで
あるDeependを生き残ります。

最初の2つのリンクはプレーンPHPで実行されますが、それでも非常に役立ちます。

于 2012-08-23T10:25:06.450 に答える