私は、特定のSQL Server/CEデータベースのPOCOとリポジトリを生成するコードジェネレータを作成しました。クラシックなADO.Netを使った簡単なCRUDプロシージャだけです。私の質問は、カスタムコードジェネレータよりもL2S/EF4のようなORMを使用する理由は何ですか？ 2〜3年ごとマイクロソフトではいくつかの新しいデータアクセスフレームワーク/テクノロジを提供していますが、常に最新のテクノロジに触れることができないかなりの開発者を知っていますが、いずれもクラシックADO.Net、既存のコードと新しい機能を開発する方法。 ORMツールは今日必要なものをもたらすか、または古典的なADO.Netに固執することができますか？コードジェネレータとORM
ありがとうございました！
実際には、プロジェクトの要件と開発プロセスによって異なります。 ORMには多くの人が集まり、テーブルに多くの喜びをもたらしますが、いくつかの異なる機能を購入するだけでは、精神的/肉体的に必要なものが失望することがあります。
既存のスキーマをアプリケーションロジック（スキーマを管理する）とアプリケーションロジックをスキーマ（ORMがスキーマを管理する）にマップするORMの2種類があります。あなたは、各環境でかなりのDBA作業を行う/繰り返す必要があることを緩和しないので、最初の種類を避けるのが好ましいでしょう。すなわち、すべての開発者が適切なスキーマを実行していることを確認する必要があります。適切なコードを実行してください。 2番目の種類は、基になるデータベースを使って事実を完全に抽象化することができるので、アプリケーションドメインだけに集中することができ、devsが幸せになります。
管理不能なリモートDBインスタンスに対するローカル開発の努力がなくなり、相互RDBMSのニュアンスがなくなり、ストアドプロシージャがなくなり、ハードコードされた参照を伴うクエリがなくなり、複雑なSQL移行クエリが不要になりました。
だから、理想的にあなたのORMは必要があります。
その他のすてきな糖：
を覚えておいてくださいを生成するための
DBAが複数の災害に巻き込まれる可能性があることをプログラマーが理解できない場合、この栄光のすべてをDBAが必要なくなったときに、この回答が本当に指摘しておかなければなりません。私が見た最悪のケースは、データベース開発者がいない19人のJava開発者でした。彼らはあなたが泣かせるように多くの問題を抱えていました。あなた自身の危険でデータベースがどのように機能するかを無視する。 –
まあ、わかりやすくするために、または私がさらに下降する前に、DBAの実際の役割への唯一の言及が最後の段落でなされました。言うまでもなく、あなたが完全に理解していないものでは決して**働かないといけません。これは、無謀な行動であり、さもなければ不本意なことを示唆しているからです。 –
私は個人的には*コード志向のアプローチ（ "ORMはDBスキーマを管理する"）を嫌っています。私はE/R + Data - > Modelから行きます（少なくとも往復*オプション*があればいいです、少なくとも、増分変更のサポートが必要です）。しかし、スキーマは私のプロジェクトに独自の人生を持っています。 –
依存;あなたはデータベースを使って無駄な忙しさをするのが好きですか、それともすべて生成されるのが好きですか？
本当に、私にとっては全く疑問はありません。すべての知っているプロジェクトはORMで始まり、私にとってはLLBLGenが最高です。それは無料ではありません。しかし、それはデータレイヤーの開発に多くの時間を節約し、使いやすい構造を提供します。
本当に、どのように時間を費やしたいかを決めることです。あなたがLLBLGenのようなものと比較したときに正当化することができるいくつかの一連の理由のために、データレイヤーで働くことに価値があることが分かったら、それを行います。しかし私のために、私はしません。
もちろん、私はあなたに同意する、常にORMを変更することは理想的ではありません。ですから、あなたが開発したいスタイルに最適なものとプロジェクトを構造化する方法を決定するのに（おそらく数週間）少し時間を費やしてから、それを実行することをお勧めします。ほとんどの主な方法は今日でも非常にうまくサポートされているので、そのうちの1つを選択して標準化することには間違いがありません。
ありがとうございました！ 「無駄なデータベースの忙しさ」に関しては、ORMを使ってできるだけ速くDALを設定することができます。私は完璧なORMを探してNHibernateを選択するのに1ヶ月を費やすことができましたが、数ヶ月後にMSはEF5を出荷し、それは次の大きなものになります（または6ヶ月後ではない）既存のコードを正常にリファクタリングするために、この新しい大きなことを学ぶためにしばらく時間を費やす必要があります。 –
@šljaker。最初の部分は冗談だった。しかし、真剣に、それは容易にする必要がある継続的なメンテナンスです。私はLLBLGenの方が、（修正や再生などが必要な）たくさんのSPを生成したものと比較して、これが簡単だと分かります。私は新技術に関してあなたが言っていることを聞いています。だからあなたは座って、今は良いものを見つけて、それに同感できる良い道を持っている必要があります。確かに、チームを常に変化させることはできません。強い理由がある場合にのみ変更してください。 –
単純なCRUDの場合、オブジェクトが表コードを表す場合は、ジェネレータが目標を達成できます。オームズを使用すると、オブジェクトの関係を複雑でオブジェクト参照を横断する必要があるしている
要するに、表とオブジェクトの間の単なるマッピングが必要な場合は、ORMを使用すると便利です。したがって、あなたはORMの機能リストをチェックアウトし、必要があれば自分自身に質問する必要があります。
コードジェネレータと完全なORM：データマッパー（以前はiBatisとして知られていたMyBatisのようなもの）の間には別のものがあります。
ORMに有利な点は、コンパイル時のチェックです。エンティティフレームワークを例として使用します。これはORMとして使用するためです。
開発中にデータベーススキーマを変更する必要がある場合（列、テーブルなどを削除する）、データベースからモデルを更新してからコンパイルします。列や表が参照された場所は、コンパイル時のエラーとして表示されるため、実行時に標準のado.netでしか認識されないバグを簡単に見つけ出すことができます。
もう1つ考えているのは、アドホックなクエリです。テーブルのデータをほんの数列だけ取り戻す場合はどうしたらよいでしょうか？生成されたコードを使用して、新しいクエリ、データで満たすためのクラスなどを追加する必要があります。ORMを使用すると、匿名クラスが生成され、忙しい作業を経る必要がなくなります自分自身を作ること。
本質的に、ORMは、自家製の解決策が一般的にしていないすべてのエッジケースを処理します。
var q = from c in ctx.contact
where c.contactId < 4
select c.firstName, c.lastName;
foreach(var temp in q){
string fullname = temp.firstName + " " + temp.LastName;
}
šljakerは、ORMと生成されたコードについてアドホックなクエリに対してではないことを尋ねました –
それは本当ですが、常にカスタムクエリを実行する必要があります。生成されたコードで作成されたものはすべての状況をカバーしません。 – Neil
すべてのORMに「コンパイル時間のチェック」があるわけではありません。 –
ウェブプログラミングに行きました。新しい言語では適切なデータ処理が不十分だったため（ORMの必要性が認識されています）、同時にすべてのコード生成プログラムを構築しました。一度も振り返らないでください。
私がORMを考慮しない理由の1つは、データベースの仕組みを実際に知っているからです。ありがとうございます。リレーショナルデータベースを使用していないように見えるようにしようとするものではありません。できるだけ少ない作業でデータベースの力を得たいと思っています。それはORMではありません。彼らは何についてではありません。
私の経験上、良い辞書ベースのジェネレータは、真実なDRYプログラミングです（自分自身を繰り返さないでください）。DBを使って作業することから私を解放し、重要なことに集中することができます堅実なテーブルデザインの上に書かれた良いビジネスロジックを得ています。
EDIT：二つのより多くのポイント：何もない場合はORMはそんなに怒りであるとして、誰の人を見つけるのは難しいですだけれども
1）非ORMルートを行くには、、、孤独ですそれを必要とすることはありませんし、ポイントを見ていない。しかし、技術的な判断であなたを導かせてください。
2）数年前、私はブログエントリ「ORMを使用しない理由」を書きました。これはあまりにも炎症性であったためリンクしません。しばらくして、なぜORMを客観的に見て、炎症を起こすことなく価値がないのかを理解しようとしました。そのリンクは：http://database-programmer.blogspot.com/2010/12/historical-perspective-of-orm-and.html
これらはすべて非常に有効な点です！私はいくつかの良いORMの人気が高まっているのは、データの2つの現実（あなたのスキーマで指定されたものとアプリケーションロジックの上に構築されたもの）を開発し維持する必要があるという問題に取り組んでいるからです。私たちはデータベース全体をうまく利用しているので、SQLは明確な真実性のステートメントを採用しているため、DBの通信と保守を処理するためのライブラリを簡単に作成できません。結局のところ、ビジネスロジックだけに集中したいのであれば、ORMは即座にあなたを獲得します。 –
ビジネスロジックに関するKenの[ブログ投稿]（http://database-programmer.blogspot.com/2011/01/business-logic-from-working-definition.html）は、彼の答えに上記を追加すると思います。 –
私の意見では非常に良い質問です。 – Earlz
誰かがあなたのプロジェクトを引き継ぐ必要があるなら、彼はEF4やNHibernateを知っている可能性がありますが、自宅で解決される可能性はほとんどありません。もしあなたのソロプログラマーなら、問題ありません。あなたが会社のチームの一員である場合：巨大な問題。 –