分離ストレージを使用した Windows Phone での永続化モデリングのさまざまなオプションを検討しています。私が思いついたアイデアの 1 つは、オブジェクトを保存する目的でリポジトリやその他のエンティティを作成するのではなく、各オブジェクトが独自の永続性を処理するという概念でした (もちろん、それは理にかなっています)。
この永続化の方法に関する良い情報を見つけることができないようで、ある種のアンチパターンに出くわしたのではないかと思います。
この方法で持続性に近づいた人はいますか? もしそうなら、このアプローチに関してあなたの賛成または反対は何ですか。
ソフトウェア開発には否定できない真実がいくつかあります。
他にもあります ( :) ) が、これらはあなたの質問に答えるのに十分です:
リポジトリを使用して、オブジェクトをテストし、永続性について何も知らず、データ ストアを交換できるようにします (ネットワーク経由でも可能です!)。
Active Record パターンについて話しているようですね。一部の人々にとっては機能しますが、それに対する批判があります（主にテスト容易性/懸念の分離の観点から）。
最大の問題は、永続化ロジックがすべてのクラスに分散してしまうことです。これはすぐに肥大化につながる可能性があり、コードベース全体に永続化テクノロジに関する仮定が埋め込まれます。オブジェクトを保存する場所や方法を変更する必要がある場合、これは面倒です。
これらの仮定は、自動化されたテストをより困難にします。これは、回避する必要のある永続レイヤーの依存関係があるためです。オブジェクトにリポジトリを挿入して、このようなものの一部を打ち消すことができますが、とにかくリポジトリを実装しています。:) 可能であれば、コアクラスを完全に永続性を無視したままにしておくことをお勧めします...
プラス面としては、これは人々が把握しやすい単純なパターンであり、軽量のプロジェクトで物事を成し遂げるための迅速な方法です。クラスの数が少ない場合は、A から B に到達するための最も速い方法になる可能性があります。小規模なプロジェクトで個別のリポジトリを構築していることに今でも気付きますが、ビジネス ロジックに永続性が混在していることに耐えられません。
短所：
長所：
基本的に、データ モデルがフラットで単純で、アプリケーションの要件が控えめである場合、Active Record が適切な選択になる可能性があります。ただし、マッピング要件がもう少し複雑になると、うまくいかなくなります。このような場合、Data Mapper のようなより堅牢な ORM パターンが適切になります。
これは、テストが非常に難しくなり、プロジェクトで主要なリファクタリングを実行する必要があるまでの時間を短縮することになります。
1日の終わりに、プロジェクトの目標と懸念事項を比較検討し、テスト/検証可能性/クリーンネスの喪失がより単純なシステムを取得する価値があるかどうかを判断する必要があります。
単純なアプリケーションの場合は、DAL層を削除して、より単純なモデルを選択しても問題ありません。アプリケーションに多くの可動部分があり、かなり複雑な場合でも、コードを適切にテストおよび検証できるようにするために、DALを削除することは避けます。
それは、データ アクセス レイヤーを使用することに直面して飛んでいます...それに問題があるわけではありません。