2

MVC3 NHibernate/ActiveRecord プロジェクトがあります。プロジェクトは順調に進んでおり、モデル オブジェクト (ほとんどの場合、3 つまたは 4 つのクラスの 1 つの巨大な階層) を少し使いこなしています。

私のアプリケーションは分析ベースです。階層データを保存し、後でスライスしたり、グラフに表示したりするので、実際の関係はそれほど複雑ではありません。

これまでのところ、私は ORM からあまり恩恵を受けていません。これによりクエリが簡単になります (ActiveRecord) が、完全なオブジェクトよりも必要な情報が少なくて済むことがよくあります。また、複雑で複数の選択とコレクションに対する反復を介して「難しい」クエリを記述する必要があります。生の SQL の方がはるかに高速でクリーンです。

この場合、ORM を捨てて生の SQL に戻ることを考えています。しかし、ソリューションを再設計する方法がわかりません。データベース層はどのように処理すればよいですか?

  • オブジェクトを照会するための静的メソッドを使用して、モデルごとに 1 つのクラスを使用する必要がありますか? または、DB を表すクラスを 1 つ持つ必要がありますか?
  • 既存のコードを多かれ少なかれ健全に保つために、ActiveRecord (または独自の ActiveRecord のような実装) の下に独自のレイヤーを作成する必要がありますか?
  • ORM メソッド (保存/削除など) をモデル クラスに結合する必要がありますか?
  • テーブル構造を変更する必要がありますか (すべてのフィールドを含むクラスごとに 1 つのテーブル)。

アドバイスをいただければ幸いです。最適なアーキテクチャとデザインを見つけようとしています。

4

1 に答える 1

3

私を含む多くの人は、主に SRP を壊し、POCO オブジェクト (ドメインを特定の ORM に密結合) を許可しないため、ActiveRecord パターンはアンチパターンだと考えています。

そうは言っても、単純な CRUD の場合は ORM に勝るものはありません。そのため、その種の作業のためにある種の ORM を維持します。アプリケーションを再構築して、POCO オブジェクトと、別のプロジェクトの ORM 実装の仕様で何らかの種類またはリポジトリ パターンを使用するだけです。

「ハード」クエリについては、小さな ORM ( Dapper、PetaPoco、またはMassiveなど) を使用してビューごとに 1 つのクラスを作成し、独自の生の SQL でオブジェクトをクエリすることを検討します。

于 2012-09-12T23:43:15.963 に答える