現在、Active Recordパターンを実装するモデルを定義したWebアプリケーションを開発しています。各モデルは、Entityプロパティを指定し、他のクラスに簡単に注入できるようにするインターフェイスによっても定義されます。これは、単体テストに特に役立ちます。データベースの実装を抽象化するために、Repositoryパターンで各モデルを実装することを楽しみにしています。
例:記事:
ArticleInterface
- title
- content
ArticleRepositoryInterface
- getArticle(title)
- saveArticle(ArticleInterface)
ArticleRepository implements ArticleRepositoryInterface
- constructor(ArticleInterface)
- ArticleInterface getArticle(title)
- saveArticle(ArticleInterface)
Article implements ArticleInterface extends ActiveRecordModel
どちらのパターンも今日のWeb開発フレームワークでは非常に人気がありますが、それらを統合する方法はわかりません。 Active Recordパターンの定義は、データベーステーブルの行をラップし、データベースアクセスをカプセル化し、各オブジェクトプロパティをデータベーステーブルにマッピングします。
各モデルリポジトリをARを実装するモデルとどのように統合する必要がありますか?
ARを実装するモデルを使用し、すべてのデータベースメソッドを継承し、それをすべてのARデータベースメソッドをラップするリポジトリに注入する代替手段はありますか?
このシナリオのベストプラクティスは何ですか?
リポジトリパターン:
ドメインオブジェクトにアクセスするためのコレクションのようなインターフェイスを使用して、ドメインとデータマッピングレイヤーの間を仲介します。
選択したデータマッピングレイヤーはアクティブレコードです。エルゴ、リポジトリは、アクティブレコードパターンとビジネスドメインの間の抽象化の追加レイヤーを提供するソフトウェアパターンです。
各モデルリポジトリを、ARを実装するモデルとどのように統合する必要がありますか?
コレクションのようなインターフェイスをビジネスドメインに返すメソッドを提供し、Active Recordを使用してデータベースから必要な結果を取得します。
ARを実装するモデルを使用し、すべてのデータベースメソッドを継承し、それをすべてのARデータベースメソッドをラップするリポジトリに注入する代替手段はありますか?
Active Recordの代わりに、Table Data Gateway、Row Data Gateway、Data Mapperなど、他の方法でデータベースにアクセスできます。
このシナリオのベストプラクティスは何ですか?
パフォーマンスと保守性の観点から、ソフトウェアの機能要件と非機能要件を最もよく満たすプラクティス。
アクティブレコードとリポジトリパターンの大きな違いは、私の意見では、エンティティインスタンスと基礎となるストレージ間のリンクの所有者です。
Active Recordは1つのバッキングストレージに接続されているため、シンプルですが柔軟性が低くなります。
エンティティのライフサイクルを誰が管理するかに関しては、どちらか一方を選択する必要があります。
ただし、それ以外は、ハイブリッドのようなものを作成できます。エンティティはそれ自体を管理します(つまり、.save()や.delete()などのアクティブレコード->メソッド)。 ())。