1

たとえば（逐語的ではありません）

/**
@Entity
*/
class Event
{
   /**
      @Column 
   */
   protected $time_start;
   /** .. */
   protected $time_end;

   /** getters, setters, etc */

   /** @return duration of event as a string, non-table function */
   public function getDuration() { ... }
}

それとも、ORM は単なるテーブルであり、それ以上のものではありませんか?

誰もが独自の意見を持っているため、これは主観的な見方になる可能性がありますが、そこでのプログラミング、および実行すること、および実際に実行してはならないことにおいて. これがそのケースの1つであるかどうか疑問に思っていました。

4

2 に答える 2

1

いいえ、それは良い考えではありません。他に何もないとしても、単一責任の原則に違反することになります。

ORM を作成している場合、インスタンスはデータの保存/取得のみを処理する必要があります。あなたの例getDuration()では、ドメイン ビジネス ロジックの一部であり、ドメイン オブジェクト内に存在する必要があります。

基本的に、ここで扱っているのは、データ マッパーとアクティブ レコードパターンの違いです。また、SOLID の原則に準拠するコードを作成しようとしている場合、アクティブ レコードはアンチパターンと見なされ、長期的には技術的負債が軽減されません。

于 2012-07-04T23:50:49.283 に答える
0

機能を持たないアプリケーション固有の理由がある場合を除いて、答えは大きなイエスです。理由を説明しましょう：

  1. OOP では、オブジェクトは単なるデータ構造ではありません。状態と動作を結び付けます。これは OOP の基本原則です。状態があり、状態を変更するメソッドがあります。エンティティとは何ですか？それはオブジェクト、ビジネス オブジェクトです。ビジネス オブジェクトには、ビジネス データとロジックが含まれます。そのため、ビジネス ロジックを実行するメソッドが必要です。ビジネス オブジェクトからビジネス ロジックを削除することは、OOP の本質に反します。最終的にはそのロジックをどこかに実装する必要がありますが、それは適切な場所ではありません。そのコードは何らかの形でビジネス オブジェクトの状態にアクセスする必要があり、ほとんどの場合、そもそも OOP を使用する理由の 1 つである情報隠蔽 (カプセル化) の原則を破ります。

  2. さて、ORMについて！ここでは、オブジェクト指向設計と ORM という 2 つのニーズを満たす必要があります。ここで、どちらが優先されるか、またはどちらが先かを尋ねます。最初に ORM (またはその他のストレージ手段) を検討してから、クラスを設計しますか? または、クラスを設計してから、それらをマップ/保存しますか? 最初の方法が正しい方法です。アプリケーションを設計してから、ORM をこの設計に従わせます。

  3. 非アクセサ メソッドを使用すると、ORM を使用できなくなりますか。番号。これらのメソッドは、オブジェクトに ORM を持つことを妨げません。ORM フレームワークの設計者は、設計時にその原理を知っていました。

于 2012-07-05T16:48:09.400 に答える