プロジェクトへのデータアクセス戦略の切り替えは？

Question

プロジェクトでは、データアクセスレイヤー（DAL） を、 のコードを自動生成するビジュアルデザイナーを実装しました（ここでは、厳密な型指定のデータセットと.NETのDataSetTableAdapter）。

しかし、ソースコントロールを使用して DALに新しいものを編集し追加するのは面倒です。 （私たちの場合：ADO.NET SqlCommandsなど）のSQL文を手作業で書くことで、新しいデータアクセス をコーディングし始めました。

しかし、データアクセスの方法を混在させることにも心配しています。 あなたは何をお勧めしますか？ 自動生成メソッドを使用すると、 などの変更が必要な場合は、 が「手動」のSQL文 に変換され続けますか？

編集：いいえ、回答 に触発され、データアクセス戦略の切り替えの一般的な問題に対処するために、私は質問の定式化を一般化しました。

モデルデータの取り扱いはあまりオブジェクト指向ではありません。 カスタムオブジェクトの代わりに.NET DataTablesを使用します。

Answer 1

手動ADOに変換するか、データセット+テーブルアダプタを使用するかのどちらかを選択する場合は、データセットを使用する方がよいと思います。あなたはそれを使用して無料のCRUDを取得します。したがって、価値を与えないsqlの作成と保守に費やされる時間が短縮されます。

あなたの質問では、データセット+テーブルアダプターのアプローチから離れていくための議論になるかもしれない、もっとオブジェクト指向のアプローチのように聞こえるわけではありません。

対処するビジネスロジックがますます複雑になる場合は、OR-mapper + pure objectsドメインにもいくつかのリサーチ/プロトタイプ作成が必要な場合があります。 RADのアプローチではそれほど効果的ではありません。私はLinq 2 sql（単純なスキーマ/オブジェクト構造を持っていて、オブジェクトとテーブルの1対1のマッピングに満足しています）か、私があなただったらNHibernateをチェックします。 Entity Frameworkは成熟していません。次のバージョンはより良いでしょうが、それはまだ潜在的に長い時間です。

Answer 2

DALを完全に書き換えている場合は、おそらくSprint.NETまたはなどの永続性フレームワークを調べる必要があります。

Answer 3

...またはRob ConeryからSubSonic :)

あなたはプロジェクトページで見つけることができる少なくとも3本の動画を参照してください。

Answer 4

はい、必要に応じてリファクタリングしてください。私は他の答えに同意しないと物事を混乱させるが、別のデータアクセスフレームワークを使用して、別のシステムの頭痛を交換することがあります。快適な基礎を身につけましょう。

Answer 5

まっすぐな "裸の" ADO.NETに行き、すべてのDAL作業をコードで手作業でやっているように思えます。私は間違いなく他の人（NHibernate、Subsonicなど）によって推奨されているようなORマッパーを見ることをお勧めします。

SQL Serverのバックエンドで.NET 3.0以降を使用している場合は、より簡単なシナリオ（データベーステーブルからデータベースへの1対1マッピング）のために、Linq2SQL（その死の噂は大きく誇張されている） （多くのテーブル、ドメインモデルでのオブジェクト継承の多く、複雑なマッピングシナリオ）のために、Entity Frameworkを使用することができます。

EFは最近、IMHOと新しいバージョンのEF v4（.NET 4.0とVS 2010がリリースされる予定です）を一部正当化しています。

マルク・

Answer 6

DALは、任意のアプリケーションの通常、ほとんどの過剰設計の部分です。それを単純なものにして、あなたが今必要とするものを構築するか、またはすぐに必要とするものを合理的に予測します。 SqlCommand、SqlDataReaderなどは、データベースへの実際の接続、データベースからの読み取り、およびデータベースへの書き込みのナットとボルトに比べて、まだ比較的抽象的です。

しかし、一般的なアプローチを1つだけ使用すると、コードが読みやすくなります。