web-dev-qa-db-ja.com

Java ORMなし、埋め込みSQLなしのWebアプリケーションを設計するにはどうすればよいですか?

編集:元のタイトル:ORMを使用する利点についての質問。

学習目的でORMを使用したいのですが、nhibernateを試しています。チュートリアルを使用していますが、実際のプロジェクトがあります。 「古い方法」を使うか、ORMを使用できます。メリットを完全に理解しているとは思いません。一方では、データベースを変更してデータベースに依存しないように、コードで抽象化を作成できます。一方、実際にデータベースの列を変更すると、すべてのコードを変更する必要があるようです。

データベース、ORM、コードを変更する代わりに、ORMなしでアプリケーションを作成し、データベースを変更してコードを変更しないのはなぜですか?彼らのデータベース構造はそれほど変わらないのですか?

ORMは非常に多くの人に利用されているため、本当のメリットがあると思います。私はまだそれを手に入れるかどうか確信がありません。

ありがとうございました。

編集:チュートリアルでは、ORMを機能させるために使用される多くのファイルがあります

http://www.hibernate.org/362.html

アプリケーションが変更された場合、「適切な」抽象化レイヤーがあるというだけで、多くの追加作業が必要になります。私はそれに慣れていないので、維持するのはそれほど簡単ではなく、また余分な作業のように見えます。

編集:これは私が繰り返し返してきた古い質問です。 ORMを使用せず、埋め込みSQLを使用せず、.NET LINQ-to-SQLを使用せずにアプリケーションを適切に設計する例について問題がないかどうかを確認します。私はJava=の世界にいるので、どうすればよいか迷っています。これはWebアプリケーションです。Springも他の世俗的なフレームワークもありません。JSP、JSTL、EL、 HTML、JavaScript、CSS、Java、Tomcat。何も省かなかったといいのですが、そうです、古い質問であることはわかっています。

58
johnny

なぜ、ああ、なぜ、業界はこのコンセプトの災難に非常に慣れているのですか?以前の回答のいずれも、@ johnnyの懸念に適切に対応していません。それらはすべて、データベースプログラマーが直面している具体的な問題をうまく回避する、中途半端な手振りの正当化です。

@TheTXIの答えは、同じ質問をするときに私が得る典型的な応答です:レイヤーの分離。どういう意味なの? wantでレイヤーを分離するのはなぜですか?または、もっと重要なことですが、リレーショナルレイヤーとは異なる追加のレイヤーを作成すると、そのレイヤーからの正規マッピングであると思われますが、どのようなメリットがありますか?

さらに、(@ johhnyのまだ答えられていない点)これはどのように私たちを変化から保護しますか?データベースが変更された場合、ORMレイヤーはほぼ確実に追随する必要があります。実際、オブジェクトレベルで結合テーブルをモデル化しないというデフォルトの方法では、テーブルがいくつかの余分な列を必然的に大きくするとき、オブジェクトモデルにいくつかの余分なフィールドを追加するだけでなく、トポロジーと強制も変更するため、これはさらに悪化します。たくさんのコード書き換え!これは変更管理の災害であり、関係の誤解された見方(それらがオブジェクトを表すと考える)がどのように災害に対処するかの典型的な例です。リレーショナルデータベースをプログラミング言語の一致する概念に直接マッピングしただけでは、これは発生しませんでした(LINQ-to-SQL、およびnot LINQ-to-EFと考えてください)。

このスペースで最大の未回答の質問—部屋の中の象—は、次のとおりです。ORMが解決するはずの問題は何ですか。 「オブジェクトリレーショナルインピーダンスミスマッチ」とは言わないでください。それはちょうど別の手を振ってフォブオフです。インピーダンスの不一致がある理由と、データベースに行く言語ではなく、データベースがその言語に来る理由を説明してください。私の説明によると、ほとんどのプログラミング言語はリレーショナルデータの表現と操作が苦手ですが、これは歴史的現実から脱却し始めています(LINQ-to-SQLはその方向への最初の最初のステップでした)。サウンドアーキテクチャのベースとなるもの。

ORMが非常に複雑になっているのには理由があります。遅延読み込み、キャッシュ、困惑するような永続性と所有権のセマンティクスの配列などがあります。また、キーボードでこれらの余分な処理を行うと、基本的な問題を効率的に解決できなくなる理由があります。 「どのメンバーのペアが複数のグループを共有しているのですか?」のような問題。リレーショナルモデルは、ネットワークモデルや階層モデルがそのような問題の重みでひざまずいていたときに考案されました。それは新鮮な空気の息でした。今、私たちは皆、猫のおしっこでいっぱいの古い砂場に戻ることを切望しているようで、私たちは何か新しいものを発明したと思います(私たちが鼻を抱えている限り)。

(私はこの回答について自由に反対票を投じられることを完全に期待しています。しかし、そうするときはコメントを残してください。理由がわかっている限り、間違っていると言われても構いません。)

編集: @Chrisにコメントしていただきありがとうございます。それは私に対処するためのいくつかの具体的なポイントを与えます...(以下で@Chrisを頻繁に取り上げますが、私は彼を特に仕事に連れて行こうとはしていません。彼の応答は、私が議論するときにいつも聞く種類のコメントの典型ですだから私は彼が私の批判を個人的な侮辱として受け取らないことを望みます;彼らはそのように意図されていません、そして私は彼が応答するのにかかった時間を本当に感謝しています)

まず最初に、@ Chrisのコメントと回答で明らかな誤解をいくつか明らかにしましょう。

  1. 明らかな理由と、それほど明白ではない理由から、コードで生のSQLを推奨していません(たとえば、SQLは代数でも計算でもないため、関数分解を事実上不可能にします)。
  2. 私はモノリシックなアプリケーション設計を推奨していません。レイヤーは一般的に良いことです。
  3. 特別なフィールド、メソッド、属性など、ラインノイズの多いオブジェクトモデルの汚染は推奨しません。しかし率直に言って、ドメイン/オブジェクトモデルはORMユニバースにのみ存在するため、これはストローマンです。 LINQ-to-SQLにはこれらのすべてのクラスにノイズの多いビットがたくさん含まれていることを知っていますが、それらは舞台裏の配管です。そのコードを編集したり、一般にそれを見たりすることはできません。

異論に対するいくつかの異論:

  1. アプリケーションをデータベースから独立して構築できるという主張は根拠がありません。概して、ORMはデータレイヤーへの正規のマッピングにすぎません(テーブルFooとBarはクラスFooとBarになり、テーブルFooBarはクラスFooとBarの間のある種の不気味な関係になります)。このマッピングには余計な余裕がないため、データモデルを変更すると、ほぼ確実にオブジェクトモデルに対応する変更が必要になります。これは私の見解では良いことです。対応するデータベースモデルから根本的に分岐したオブジェクトは、関係者すべてにとって追加のメンテナンスの頭痛に過ぎないからです。
  2. ORMがデータモデルの独立性を生み出すという幻想が捨てられると、データモデルへの直接結合の悪に関するすべての抗議は根本からなくなります。しかし、私はこれを単に却下するよりも、これをもう少し追求したいと思います。カップリングはシステム設計の重要な機能です。ある時点で、決定と仮定を行う必要があります。 1つの「物」テーブルを使用してすべてをプログラムすることはできません。ドメインに特定の特定の概念が含まれていることを確認し、それらの概念を尊重するスキーマとコードを作成し、それらを一流の市民として扱い、ハードコードする必要があります。アプリケーションはずがデータベースから独立しているという考えは誤解されています。データベースは、ビジネスの知識の最も純粋な表現です(またはそうする必要があります)(これが常に当てはまるわけではないことはわかっています。これについては後で説明します)。このようなデータモデルはビジネス自体に本質的な変化が生じた場合にのみ変化するため、この表現と組み合わせることで、回復力の最も強力な保証が得られるはずです。つまり、適切に設計されたデータベーススキーマに結合することは非常に良いことです。
  3. 階層化はそれ自体が目的ではありません。特定の目標を達成しているので良いです。上記のポイントは、ORMが行う方法でのデータベースとアプリの間の階層化は、変更に対する回復力の本当の目標を達成するために効果的でも必要でもないことを示しています。これは、優れたデータベース設計によって実現されます。
  4. @Chrisは、データベースに物事を指示させるOO設計です。これは十分に真実ですが、OO設計がモデル化する最良の方法である場合にのみ興味深いです知識。市場でのOODBMSのほぼ完全な障害は、これが当てはまらないことを示唆しています。リレーショナルモデルは、その述語論理の基盤により、OO設計と同じ表現力を持ち、 OOモデルのグラフ理論的な複雑さ。
  5. @Chrisが今日の問題(つまり、NoSQLの動き)を解決しないという理由でリレーショナルモデルに反対することは、完全に適切ではありません。 NoSQLは「リレーショナルモデルなし」ではなく、「SQLなし」を意味します。残念ながら、NoSQL運動の支持者でさえ、この点に関してまったく無知のようです。 SQLには深い欠陥があり、その多くはリレーショナルモデルからの根本的な逸脱に起因します。 SQLは吸い込むのは、赤ちゃんをお風呂で吐き出すのはかなり露骨なケースなので、リレーショナルモデルを放棄する必要があると言います。
  6. ORMを使用しないと、アプリケーションを構築する労力がnot 3倍になります。これは馬鹿げた主張であり、@ Chrisでさえ、バックドアを開いたままにしているようで、codegenの代替案に対してバックハンドで賛辞を送っています。 LINQ-to-SQLのsqlmetalなどのCodegenツールは、アプリケーションのデータモデルがデータベースのデータモデルと完全に異なる必要があるというドグマに慣れていない場合に最適なソリューションです。

ORMに関する私の自身の経験は、ORMがチュートリアルでうまく機能し、現実の世界に無限の苦痛と欲求不満を引き起こすことでした。 LINQ-to-SQLがORMの動機となった多くの問題を最初から修正しているので、私はそのような拷問に身を投じる理由はないと思います。

重大な問題が1つ残っています。現在のSQLデータベースでは、物理層と論理層の分離に対する意味のある制御は提供されていません。テーブルからディスク上のものへのマッピングは大部分が修正されており、完全にSQL DBMSの制御下にあります。これは、明示的に2つを分離したリレーショナルモデルの計画の一部ではなく、論理モデルによって提案されたものとは完全に異なる構造でディスクに格納できるデータの一貫した論理表現の定義を可能にしました。たとえば、システム(またはdba)は、パフォーマンス上の理由から、高度に正規化された論理モデルを物理的に非正規化できます。 SQLエンジンではこのような懸念の分離が許可されていないため、論理モデルを非正規化したり、必要に応じて拷問したりするのが一般的です。その結果、論理モデルは常に正確であるとは限らないため、データベースを知識の最も純粋な表現として使用するという理想を完全に実現することはできません。しかし実際には、デザイナーは通常、データベースからドメインモデルへの正規マッピングに固執しています。

118
Marcelo Cantos

私のNHibernateの経験では、Visual Basicに少し似ています:簡単な問題reallyが簡単になりますが、それよりも難しいことも本当に難しい、あるいはまったく不可能です。

基本的な考え方は、ORMは永続化コードを記述する必要がないということです。このようなコードには多くの重複があるため、そのコードを特定のビジネスレイヤーに固有のものではなく一般的なものにして、プロジェクト間で再利用するのは非常に魅力的です。ここまでは順調ですね。単純なオブジェクト階層とビジネス要件の場合、これは実際にうまく機能します。データベースが変更された場合は、そうです、ORMマッピングファイルを変更する必要がありますが、通常は非常に簡単で、データベースにアクセスするコードを変更するよりも1か所で変更するだけで済みます。

問題は、データベースと要件がより複雑になると、ORMが追いつくことがますます難しくなることです。したがって、ORMはますます複雑になります。また、allの場合に効率的に実行する方法を理解するのに十分スマートではないため、ショートカットを取得し、非効率的にいくつかのことを行います。さらに、全体的なアイデアは透過的に機能するということなので、これらのパフォーマンスの問題は、ユーザーエクスペリエンスに影響を与えるほど悪化するまで見られないことがよくあります。関連する問題は、デバッグしない限りORM内で何が行われているのかわからないため、バグを見つけるのがはるかに難しいことです。 (はい、私はNHibernateコードをステップ実行する必要があり、それはピクニックではありません!)

そのため、いくつかのことについてORMをバイパスし、代わりにSQLを直接使用します。もちろん、thatコードをdoesより多くの作業であるORMを使用します。いくつかのオブジェクトを手動でロードして保存し、それを何らかの形でORMコードに組み込むコードを作成することになります。やがて、ORMが節約よりも多くの作業を作成しているかどうか、そしてパフォーマンスとバグハンティングの頭痛は言うまでもなく疑問に思われるようになります。

したがって、チュートリアルで見られるような非常に単純なアプリケーションを作成している場合は、ORMが適切に機能します。それよりも複雑な場合は、価値がないと思います。もちろん、単純なアプリケーションの場合、節約される時間の絶対量も小さくなります。私の結論:ORMを気にしないでください。 ORMはダークサイドにつながるパスです。

48
EMP

これを読む前に、ORMツールがプロジェクトに与える影響を理解するために本当に他の人が本当に迷惑を掛けているのではないかとよく疑問に思いました。 @ Evgeny、@ Marcelo Cantos、および@Jimmy Bがこれを休止しました。

要するに、彼らはORMツールを取り巻く問題のほとんどで行き詰まっています。彼らがカバーしていないか、十分にカバーしていないカップルがいくつかあります。

まず、ORMを使用してもコードが少なくなるわけではありません。 SQLの削減を意味する場合もありますが、コードの削減を意味するわけではありません。これらの行に沿って、ツールが生成したコードは間違っている可能性があります。さらに悪いことに、生成された不良コードを補正することは、フラストレーションの原因です。

次に、ORMツールは、SQLを理解する必要がないという意味ではありません。別の言い方をすれば、SQLが効果的なプログラマであることを知っている必要があります(組み込みの人のような例外があります)。これらのツールによって発行されたクエリ(種類と数の両方)は、パフォーマンスまたはリソースの観点からは十分ではありません。すでにSQLを知っている必要がある場合、なぜ自分で束縛するのですか?

第三に、ORMツールは時間を節約しません。まともなサイズのアプリケーションを処理するために、選択したORMツールを送信して送信するのに(それ以上ではないにしても)時間を費やします。傷害に侮辱を加えるために、あなたが終わったとき、あなたがそれを自分で行った場合よりもクエリの質が一般に悪いことがわかります。ポイントはORM =プロジェクトにより多くの時間を費やすこと、より悪い結果です。

第4に、DBMSの独立性は一般に時間の浪費です。ほとんどのアプリケーションは、存続期間中に1つのDBMSを使用します。 Oracle、SQLサーバー、MySqlなど。アプリケーションは、DBMSが提供する機能を利用できるため、はるかに優れています。 DBMSにとらわれないということは、サブパークエリに限定する必要があるということです。

第5に、すべてがオブジェクトである必要はありません。これは重要なことです。多くの場合、特定のデータセットをページに表示するように求められます。多くの場合、これは2つ以上のテーブルのデータを結合することを意味します。アプリは、データを表示するためだけに、これらのオブジェクトをすべて作成してインスタンス化する必要がありますか?または、クエリを実行し、選択した形式でデータを画面/ブラウザに直接出力する方がよいでしょうか?

ORMは、最も単純なものにも、多くのオーバーヘッドを追加します。ほとんどのORMは、テーブルに対して単純なUPDATEを実行するために複数のSQLクエリを生成します。

6番目、そして私の心の中で最も重要な問題:ORMはセキュリティを低下させます。もちろん、s'procsでORMを使用できます。しかし、ほとんどの人はそうではありません。 ORMを利用したほぼすべてのアプリがデータベースを公開したため、サイトがクラックされた場合、データベース全体が簡単に削除または盗用される可能性があります。 ORMツールは、オンザフライでSQLを生成します。つまり、テーブルに直接アクセスする必要があります。つまり、アプリが侵害された場合、ハッカーは直接テーブルにアクセスできます。これは、アプリケーションから少なくとも1つのセキュリティ層を効果的に削除したことを意味します。

27
NotMe

この質問はしばらく前に投稿されたことに気づきましたが、ジョニーと同じことを考えていました。 Hibernateがインテリジェントな人々によっていくつかの大規模なプロジェクトで使用されるのを見てきましたが、いずれの場合も、それは軽減されない災害でした。私の経験では、ほとんどのエンタープライズアプリケーションで最も複雑でパフォーマンスに影響を与える領域は、ビジネスレイヤーとデータベースレイヤーの間です。これが、データベースアクセスを管理可能なチャンクにカプセル化しようとするデータアクセスレイヤーを追加する理由の一部です。

ORMの使用に関して私が見た最大の議論は、「手書きのコードを削減」し、ビジネスロジックをデータアクセスから分離する抽象化レイヤーを提供することです。私はこれらのどちらも非常に単純な場合を除いて実際には真実ではないと断言します。

Hibernate(および他のほとんどのORMツール)を機能させるには、すべてのデータベースとオブジェクトの相互作用を文書化するhibernateマッピングファイルを作成するか、注釈を使用して同じ関係を文書化します。あるケースでは、テストが難しいが、それほど複雑ではないxml構成ファイルにコードを移動しました。もう1つは、ドメインモデル全体でデータベースと対話する方法のロジックを配布することです。重要なのは、実際の「コード」は少なく書いたものの、コードを構成ファイルまたは注釈に移動する!=「コードが少ない」ことです。複雑さを直接制御して軽減できるコードから、はるかに制御の少ないサードパーティツールに単純に移動します。

ビジネス/ドメイン層をデータベース層から分離することになっているORM抽象化層は、この「分離」を打ち消す微妙な効果を持つ傾向があります。 ORMレイヤーがオブジェクトモデルやデータベースの設計に、理想的ではないと見なされる方法で影響を与えるプロジェクトをいくつ見ましたか?貧弱な物理の類推を使用するには、ビジネスレイヤー、ORMレイヤー、およびデータベースレイヤーにすべて質量があると仮定します。 ORMレイヤーが単に他のレイヤーとの間に存在するだけで、他のレイヤーを変形および反らせようとする力が働きます。 ORMレイヤーで必要なため、ビジネスモデルに適合しない主キーオブジェクトを導入する必要がありましたか? ORMツールはそれを処理できないため、特に複雑なオブジェクトグラフモデルに対応するためにデータベース構造を調整する必要がありましたか?極端に言えば、ORMレイヤーの存在は、データベースの相互作用がどのように機能するかという全体像を歪める可能性があります。永続的なオブジェクトグラフを処理するサービスレイヤーの代わりに、独立して存在するかのように、ドメインオブジェクトごとに個別のデータアクセスレイヤーオブジェクトを作成することができます。私はさまざまな程度でこれらすべてのシナリオを見てきました。おそらく、それはORMツールセットの不慣れです。おそらくそれは悪いデータベース構造です。疑わしい。私が見たすべては、ORMソリューションが不十分であることを示しています。

データアクセスレイヤーが複雑で、パフォーマンスのボトルネックが発生しやすいという私の主張を受け入れた場合、なぜコードと分離を減らすという目的を達成しないツールを追加することを検討し、同時に、アプリケーションの他のレイヤーの構造?

10
Jimmy B

@Marcelo Cantosの回答に完全に対応しましたが、ORMを使用する主な利点を要約します。

永続性無視(PI)およびドメインドライブ設計(DDD)

ORMは、これらの全体的な設計パターンの両方に完全に適しています。正しいオブジェクト指向の設計では、階層的で多態的なオブジェクトを使用して、アプリケーション内でのデータの流れを表現します。優れた設計では、POCOオブジェクト(プレーンな古いC/C#オブジェクト、このWordの他の定義を見てきました)を頻繁に求めます。リストを持つ人物がいる場合、それだけが必要だからです。アプリケーションで作業するように強制する人のDataTableとアドレスのDataTableは必要ありません。それに加えて、データベース固有の大量のロジックをオブジェクトに関連付ける必要はありません。なぜ、私の個人のFirstNameフィールドに[ColumnName("First_Name")] [Length(255)] [DataType(Types.Nvarchar)]などのクレイジーな属性やコードが必要なのですか。ドメイン設計に強制されるデータベースの数を定義しますか?

手書きのコードが少ない

アプリケーション内のすべてのオブジェクトに対してSelect、Insert、Update、およびDeleteステートメントを記述してデータベースに保存する必要をなくすと、記述されるコードの行数が大幅に削減されます。これにより、何かを意味するクエリを記述するだけで済みます。また、多くのORM(NHibernateなど)には、SQLの上に階層化された言語が含まれます。この言語は、対話するように定義されており、構文的にフープで満たされにくい場合があります。

これが完全に表示されるのは、すべての単一のオブジェクトにリンクされているUserTableを持つアプリケーションを検討し、何らかの理由で主キーの名前またはタイプを変更する必要がある場合です。この時点で、データベース内のすべてのストアドプロシージャを変更する必要がある可能性があります。正しく実装されたORMソリューションを使用すると、構成マッピングをいくつか変更するだけで(または、何も変更せずに)完了します。

8
Chris Marisic

ORMツールを使用する基本的な利点は、多層アプリケーションでビジネスロジックをデータアクセスから分離するという原則を容易にすることです。 (マッピングを変更することにより)データベースの変更に応答するデータアクセスレイヤーを正常に構築できる場合、変更が行われたときにいじる必要のある全体的なコードは少なくなります。

層の分離は通常、3層またはn層のアプリケーションの目標であり、ORMはそのための優れた方法です。

6
TheTXI

プライマリドライバー:管理/保守する全体的なコードが少ない

4
Srikar Doddi

私が誰も対処していないのは、ORMが解決すべき問題についてです。 ORMが解決するはずの問題は、アプリケーション側のコードとデータベースの間の切断と、開発者がデータベースの問題に費やす時間に対処します。データベースとアプリケーションコード間の切断とは、アプリケーションを実行して、書き込まれたコードが無効な列を参照していることを認識する必要があることを指します。 ORMはこのギャップを埋め、データベース、アプリケーション、およびデータが一緒に移動するモデルを作成することになっています。コードが同期していないことがわかっているので、コンパイルします(モデルを最新の状態に保つことを前提とします)。

小規模から大規模のエンタープライズアプリケーションまで、さまざまなサイズのプロジェクトで3つの異なるORM(EF、LINQ to SQL、N-Hibernate)を使用しました。さらに、私はADO.NETでそれについて考えるのに慣れています。 DataReadersと、クラス、DataSet、およびさまざまな生成ツールへのマッピング。 3つの異なるORMで、ORMメソッドなしで、良い実装と悪い実装を見てきました。私が目にした問題の大部分はアンチパターンに戻り、特定のORMの制限を理解していません。次の記事( N層アプリケーションで回避するアンチパターン )は、これらのアンチパターンの多くを強調する素晴らしい仕事をしています。最高のソフトウェアアーキテクト、開発者、そして賢い人々でさえ、アンチパターンが生み出す問題を解決するデザインパターンや特定のデザイン原則の価値を発見する前に、アンチパターンのシェアに参加しています。

ツールがわからないことは、パフォーマンスに関する問題が発生する場所であるため、別の問題です。CRUD操作などのデータベースロジックの実行に関して、ダイナミックSQLとストアドプロシージャのパフォーマンスの違いが不明であることは明らかです。判決が下され、動的コマンドは、対応するストアドプロシージャと同じくらい効率的であることが証明されています。どちらにも長所と短所があります。重要なのは、彼らが何であるかを理解し、状況に適した選択肢を選択することです。

4
LCarter

私が自分のORMから得るすべてがストアドプロシージャを維持する必要性から私を救うことであれば、それで十分です。

ただし、ORMを使用すると、コードの設計に課される人質のようなグリップデータベーススキーマから解放されます。現実の世界とまったく同じようにコードをモデル化できる場合、物事ははるかに簡単になります。また、恐ろしい命名規則を持つ潜在的な見苦しいレガシーデータベースの構造へのマッピングを支援(および非表示)する(優れた)ORMでこれを行うことができます。何かを意味し、どこでもこのような冗長なコードを気にしない:

using (SqlWrapper sql = SqlWrapper.Create(WrapperConnectionType.ShopNet, "sStore_InsertUpdate_v4"))
            {
                sql.AddParameter("StoreId", StoreId);
                sql.AddParameter("StoreName", StoreName);
                sql.AddParameter("Region", Region);
                sql.AddParameter("PostCode", PostCode);
                sql.AddParameter("Tel", Tel);
                sql.AddParameter("Email", Email);
                sql.AddParameter("RegionId", RegionId);
                sql.AddParameter("MapImage", MapImage);
                sql.AddParameter("ShopImage", ShopImage);
                sql.AddParameter("Visible", Visible ? 'Y' : 'N');
                sql.AddParameter("TazEnabled", TasEnabled ? 'Y' : 'N');
                sql.AddParameter("Latitude", Latitude);
                sql.AddParameter("Longitude", Longitude);
                sql.AddParameter("StoreOpeningDate", OpeningDate);
                sql.AddParameter("CustomerNo", CustomerNo);
                sql.AddParameter("ReserveAtStoreEnabled", RasEnabled);
                sql.AddParameter("OpeningHoursId", OpeningHours.Id);
                sql.AddParameter("AddressLine1", AddressLine1);
                sql.AddParameter("AddressLine2", AddressLine2);
                sql.AddParameter("City", City);
                sql.AddParameter("District", District);
                sql.AddParameter("County", County);
                sql.AddParameter("CountryCode", CountryCode);
                sql.AddParameter("GoogleCategories", GoogleCategories);
                sql.AddParameter("GooglePlacesEnabled", GooglePlacesEnabled);
                sql.AddParameter("ManagerName", ManagerName);
                sql.AddParameter("MapZoomLevel", MapZoomLevel);
                sql.AddParameter("IpAddress", IpAddress);
                sql.AddParameter("FlibbleEnabled", FlibbleEnabled);
                sql.AddParameter("RegionalManager", RegionalManagerId);
                sql.AddParameter("ShutlLogin", ShutlLogin);
                sql.AddParameter("ShutlPassword", ShutlPassword);
                sql.Execute();
            }

そして、これらのタイプの戦いを撲滅させます(忘れないでください):

System.IndexOutOfRangeException
at System.Data.SqlClient.SqlDataReader.GetOrdinal(String name)

私にとっての議論はそれ以上複雑である必要はありません、私はいくつかの素晴らしいものを手に入れ、ひどいものは取り除かれます。ナフは言った、次!

ORMが従来のすべてのものの100%の代替品であると主張している人はいません。これは、SPとビューを使用し、NHibernateを使用してネイティブに呼び出し、c#エンティティに自動的にマップするため、複雑なレポートを作成するための優れたツールにはなりません。素晴らしいですが、SQLのすべての機能を備えていますが、マッピングコードはありません。

0と1の暗闇の貯蔵庫に行って、健康なc#weltanschauungのあなたの光に来てください。

1

1つの利点は、データレイヤーがオブジェクトレイヤーから分離されていることです。そのため、そのレイヤーに依存する複数のアプリケーション/プロジェクトがある場合、ORMで一度変更するだけで、オブジェクトレイヤーを参照するすべてのアプリケーション/プロジェクトで、変更します。それがないと、すべてのプロジェクトで変更を加える必要があります。

0
chrishawn