私は現在、小さな CRUD アプリケーションを設計しています。彼らのデータベースは非常に混乱しており、今後 6 か月から 1 年の間に頻繁に変更されます。私のデータレイヤーに何をお勧めしますか:
1) ORM (もしそうなら、どれ?)
2) Linq2Sql
3) ストアド プロシージャ
4) パラメータ化されたクエリ
テーブルを置き換えたり、列を頻繁に追加/削除したりできる、十分に動的な（高速かつ簡単な）ソリューションが本当に必要です。
注: 私は ORM の経験があまりなく (SubSonic は少しだけ)、一般的にストアド プロシージャを使用する傾向があるため、おそらくそれが適しているでしょう。上記の状況が許されるのであれば、Ling2Sql または NHibernate を学びたいと思っています。
ここで注意すべき重要な点の 1 つは、データベース スキーマが頻繁に変更される場合は、コンパイル時の型の安全性をある程度確保する必要があるということです。NHibernate は xml マッピング ファイルを使用するため、これが問題であることがわかりました。そのため、データベース スキーマで何かを変更しても、実行時までマッピングが壊れていることがわかりません。
また、ストアド プロシージャでも問題が発生します。
Linq2Sql を使用すると、コンパイル時にスキーマを変更するときに、コードがどこで壊れているかを正確に知ることができるという利点があります。私にとってこれは、頻繁に変更されるスキーマで作業している場合、他のすべてよりも優先されるものです
ビルド プロバイダー (Web サイト プロジェクト) のセットアップで SubSonic を検討します。プロジェクトをビルドするたびに DAL オブジェクトが自動的に再生成されるため、これはうまく機能します。そのため、コードを壊すような方法でデータベースが変更されると、ビルド エラーが発生します。
データベース スキーマが非常に複雑になり、ActiveRecord パターンの限界に達するまではうまく機能しましたが、スキーマが非常に複雑でない限り、かなりうまく機能します。スキーマが安定したら、必要なときにのみ DAL を構築するように切り替えることができます。
あなたは間違いなくORMを使いたいと思っています。どの ORM も問題ありませんが、強く型付けされたクラスを生成するものが必要です。フィールドがテーブルに追加、変更、または削除された場合、それらのクラスを再生成し、コンパイル時エラーのみを修正できるようにする必要があります。動的モデルを使用すると、多くの厄介な実行時エラーが発生する可能性があります。これはとても重要です！私は sourceforge のMyGeneration開発チームの一員です。それはあなたの問題に対する素晴らしい解決策だと思います。dOOdads、NHibernate、EasyObjects、EntitySpaces などを生成できます。より高価なソリューションを使用する場合は、CodeSmithまたはLLBLGen Proを使用してください。頑張ってください - MyGeneration の使用に興味がある方は、お気軽に私に質問してください。
EntitySpacesは、DAL /ビジネスレイヤーを1分で再生成でき、コードを失うことはありません。試用版を参照してください==>こちらをご覧ください
登録は不要で、VisualStudioでも実行できます。
EntitySpacesを使用します。あなたは私に花を送ってくれるでしょう、保証されています。単に素晴らしいです。必要に応じてデータベースを変更します。ボタンを押して、強打します。すべての変更が完了しました。カスタムコードを変更せずに。大好きです。
アプリケーションはどれくらい簡単ですか？数か月間、スキーマ/デザインの作業をしていて、実際のアプリについてあまり心配していなかったとします。. . EDM と動的データ エンティティ Web アプリケーション プロジェクトの使用を検討します。私の意見では、これにより、最小限の労力で作業を進めることができます。これにより、スキーマ、データ、およびその他のグルーブなものに集中できます。私はうまくいけば、これからあまりにも多くの否定的なバンプを得ることはありません!
新しいプロジェクト ダイアログがどのように表示されるかを次に示します。
私があなたの立場なら、私が知っていること (sprocs) を Linq2Sql で活用しようとします。Linq2Sql は引き続き sproc を使用できますが、ベルトに新しいツールを追加するという追加のボーナスがあります。Linq2XXX (X はランダムなテクノロジーであり、アダルト エンターテイメントではありません....今考えると悪い考えではありません) の構文と方法論を把握することは、次を使用するスキル セットに大きく追加されると思います。オブジェクトのコレクションに対する Linq はとても便利です。
しかし、最終的には NHibernate のようなものが長期的にはより適しています。
ただし、クラスを定義し、マッピング ファイルで目的のテーブル構造を定義し、 NHibernateの組み込みスキーマ生成クラスを使用してデータベース スキーマを作成するという、オブジェクト ファーストのアプローチを受け入れる場合に限ります。
それを逆に行う場合 (たとえば、多数のテーブルがあり、それに基づいてオブジェクト設計を行う場合)、MyGeneration + NHibernate が機能することがわかりましたが、結果のクラスにはあまり満足していません (主な理由は私は真のオブジェクト指向プログラミングに固執しています)。
なぜ変更されているのかを見て、コードを壊さないように、変更の種類を予測して一般化できるかどうかを確認してください。
フレームワークは変更への対応を容易にするかもしれませんが、より深い分析は長期的な利益をもたらします
データベース スキーマが頻繁に変更される場合は、LINQ2SQL よりも Entity Framework を優先してください。スキーマが変更された場合、L2S を使用して、
1) テーブルを削除して再度追加する必要があります (カスタマイズが失われます)
2) モデルを手動で変更します (ここで行われたように、stackoverflow で行われます)。
EF は L2S のスーパーセットであり、より柔軟に使用でき、dbms に依存しません。
あなたはすでにストアド プロシージャに満足しており、変化するスキーマを抽象化するのに十分かもしれません。ORM がストアド プロシージャに満足していない場合は、変化するスキーマの上で最新の状態を維持するビューで動作する可能性があります。
どんなソリューションでも機能します。本当に必要なのは、挿入、選択、更新、削除などの基本的な操作が機能することを保証する一連のテストです。このようにして、テストを実行し、マッピングが最新かどうかを簡単に確認できます。