私たちは利益のある特性を使用します

飼い葉Onには、特性とその使用方法に関する記事がすでにありました。 しかし、私たちが毎日書いている実際のフレームワークでの使用例はまだ見ていません。 私はSymfony2スタックのファンです。そのため、どのように特性を有益に使用できるかを示します。



Doctrineのプロキシ実装の性質により、どのモデルにもゲッターとセッターを書く必要があります。 しかし、なぜ同じことを毎回繰り返すのでしょうか？ 絶対に、すべてのエンティティにはID、2番目の名前、および多くの場合説明があります。 それで、なぜそれを特性に入れないのですか？

namespace Column; trait Id { /** * @var integer * @ORM\Id * @ORM\Column(type="integer") * @ORM\GeneratedValue(strategy="AUTO") */ protected $id; /** * @return integer */ public function getId() { return $this->id; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次のモデルを説明すると、15行ではなく1行入力するだけで十分です。

 class Book { use \Column\Id; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

素晴らしいですね



そのようなアイデアが思いついたとき、有名なKNPLabsからいくつかのライブラリを見つけました。

• github.com/KnpLabs/DoctrineBehaviors
• github.com/KnpLabs/ControllerBehaviors

すべての使い方は非常に簡単です-READMEに記載されています。



ただし、これらのライブラリはロジックのチャンク全体を追加するため、モデルコードを短くしたいと思います。

そのため、プロジェクトで使用されるほとんどの特性を別個の教義列に入れました 。

ライブラリは現在、モデルクラスで頻繁に使用されるプロパティの小さなセットです。

Book



追加しましょう。

 use Nkt\Column; class Book { use Column\Id; use Column\Name; use Column\Price; use Column\Description; use Column\CreatedDate; public function __construct($name, $description) { $this->setName($name); $this->setDescription($description); $this->setCreatedDate(new \DateTime()); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これで、いくつかのユニークなプロパティを追加し、何らかのロジックを記述できますが、モデルコードは肥大化しません。



同様に、関連するエンティティの基本的な動作を説明できます。たとえば、プロジェクトにCommentable



タイプがあり、任意のエンティティにコメント機能を追加できます。



ただし、すべてがそれほどバラ色ではありません-小さな問題があります。 データスキームが注釈から取得される場合、Strict Standartsの警告なしに再定義することはできません。



何らかの形で-私の意見では、これは非常に興味深いアプローチであり、主にコードの認識を容易にします。 エンティティで頻繁に使用するプロパティを含むPRを送信します。喜んで追加します。