問題タブ [orm]

伝統主義者は、ストアドプロシージャは、NHibernateなどのオブジェクトリレーショナルマッピング（ORM）フレームワークを使用する場合よりも優れたセキュリティを提供すると主張しています。

その議論に対抗するために、適切なセキュリティが実施されていることを確認するためにNHibernateで使用できるいくつかのアプローチは何ですか（たとえば、SQLインジェクションの防止など）？

（回答ごとに1つのアプローチのみを提供してください）

システムの典型的なストアド プロシージャは、約 20 個のパラメータを受け入れます。これらのストアド プロシージャをリファクタリングする機会もありません。私は基本的に、SP パラメータに対応するパブリック プロパティを使用して、これらの SP を (データベース プロバイダに依存しない) 「コマンド」オブジェクトにラップする独自のコード ジェネレータを作成することに頼りました。それは機能しますが、サードパーティが試行およびテストしたソリューションを好みます。

誰でも何かお勧めできますか？OleDB とストアド プロシージャをサポートするものは見つかりませんでした。

編集：SQL 6.5のため、OleDb接続が必要です（信じられないかもしれませんが）。ADO.NET は SQL 6.5 に接続できません。また、これは .NET 2.0 アプリケーションであるため、LinqToSql は役に立ちません。

Edit2: 私はすでに nHibernate と iBatis を試しました。どちらも私のニーズには合いません。前回 nHibernate を試したときは、SP が結果セットを返す必要がありました。それは私のSPには当てはまりません。どちらも手動でパラメーターを指定する必要があります。

さまざまな理由から、新しいビジネスオブジェクト/データストレージライブラリを作成しています。このレイヤーの要件の1つは、ビジネスルールのロジックと実際のデータストレージレイヤーを分離することです。

同じオブジェクトへのアクセスを実装する複数のデータストレージレイヤーを持つことができます。たとえば、ほとんどのオブジェクトを実装するメインの「データベース」データストレージソースと、ユーザーオブジェクトを実装する別の「ldap」ソースです。このシナリオでは、ユーザーはオプションでLDAPソースから取得できますが、機能がわずかに異なる場合があります（たとえば、ユーザーオブジェクトを保存/更新することはできません）が、それ以外の場合は、アプリケーションで同じように使用されます。別のデータストレージタイプは、Webサービスまたは外部データベースである可能性があります。

これを実装するために私たちが検討している主な方法は2つあり、私と同僚は基本的なレベルで意見が一致していません。どちらを使用するのが最適かについてアドバイスをお願いします。ここでいくつかの客観的な視点を探しているので、それぞれの説明をできるだけ中立に保つようにします。

• ビジネスオブジェクトは基本クラスであり、データストレージオブジェクトはビジネスオブジェクトを継承します。クライアントコードは、データストレージオブジェクトを処理します。

  この場合、共通のビジネスルールは各データストレージオブジェクトに継承され、クライアントコードによって直接使用されるのはデータストレージオブジェクトです。

  これは、クライアントコードが特定のオブジェクトに使用するデータストレージメソッドを決定することを意味します。これは、そのタイプのオブジェクトに対してインスタンスを明示的に宣言する必要があるためです。クライアントコードは、使用している各データストレージタイプの接続情報を明示的に知る必要があります。

  データストレージレイヤーが特定のオブジェクトに異なる機能を実装している場合、オブジェクトの外観が異なるため、クライアントコードはコンパイル時にそれを明示的に認識します。データの保存方法を変更した場合は、クライアントコードを更新する必要があります。

• ビジネスオブジェクトは、データストレージオブジェクトをカプセル化します。

  この場合、ビジネスオブジェクトはクライアントアプリケーションによって直接使用されます。クライアントアプリケーションは、基本接続情報をビジネスレイヤーに渡します。特定のオブジェクトが使用するデータストレージ方法の決定は、ビジネスオブジェクトコードによって行われます。接続情報は、構成ファイル（クライアントアプリは実際にはその詳細を認識/認識していません）から取得したデータのチャンクであり、データベースの単一の接続文字列、またはさまざまなデータストレージタイプの複数の接続文字列である可能性があります。追加のデータストレージ接続タイプは、別の場所から読み取ることもできます。たとえば、さまざまなWebサービスへのURLを指定するデータベースの構成テーブルです。

  ここでの利点は、新しいデータストレージメソッドが既存のオブジェクトに追加された場合、実行時に構成設定を設定して使用するメソッドを決定でき、クライアントアプリケーションに対して完全に透過的であることです。特定のオブジェクトのデータストレージ方法が変更された場合、クライアントアプリを変更する必要はありません。

• ビジネスオブジェクトは基本クラスであり、データソースオブジェクトはビジネスオブジェクトから継承します。クライアントコードは主に基本クラスを扱います。

  これは最初のメソッドに似ていますが、クライアントコードは基本ビジネスオブジェクトタイプの変数を宣言し、ビジネスオブジェクトのLoad（）/ Create（）/etc静的メソッドは適切なデータソースタイプのオブジェクトを返します。

  このソリューションのアーキテクチャは最初の方法と似ていますが、主な違いは、特定のビジネスオブジェクトに使用するデータストレージオブジェクトが、クライアントコードではなく、ビジネスレイヤーによって行われるかどうかの決定です。

この機能の一部を提供する既存のORMライブラリがすでに存在することは知っていますが、今のところそれらを割り引いてください（データストレージレイヤーがこれらのORMライブラリの1つで実装されている可能性があります）-また、意図的に言っていないことに注意してくださいここで使用されている言語は、強く入力されていること以外は何ですか。

ここでは、どの方法を使用するのが良いか（または他の方法を自由に提案するか）、およびその理由について、いくつかの一般的なアドバイスを探しています。

現在、私は非常にシンプルなウェブサイトを作成しています - 約 5 ページです。問題は、ある種のデータベース マッピング ソリューションを統合するのはやり過ぎであり、時間をかける価値があるのか​​、それとも単純な古い JNDI を使用した方がよいのかということです。データベースから読み取り/書き込みを行う必要があるものがおそらく 10 個ほどあるでしょう。これらのテクノロジーの基本的な理解はあると思いますが、ドキュメントを参照するにはまだ多くの時間が必要です。以前に決定に直面した人はいますか?

編集:申し訳ありませんが、DB接続を検索するためにJNDIを指定し、操作を実行するためにJDBCを指定する必要がありました。

高水準言語（Python、Rubyなど）で開発されたプロジェクションに手書きのスキーマを使用する必要がありますか、それともORMソリューションに自動生成させる必要がありますか？最終的には、すべてのデータを破棄せずに移行する必要があります。特定のRDBMSに関連付けてもかまいませんが、制約やプロシージャなどの機能を何らかの形でサポートできれば便利です。

誰かがC＃3.5でActiveRecordイントロサンプルを試しましたか？どういうわけか、サンプルが完全に間違っているか、単に古くなっているように感じます。XML構成はまったく間違っています。

する必要があります：

（nhibernateの構成構文を正しく理解している場合..）

私は何が間違っているのだろうと思っています。ユーザーモデルでCount（）を呼び出すと、「ユーザーに対してExecuteQueryを実行できませんでした」という例外が発生します。

これが何であるかわかりません。チュートリアルのソースは、ページのソース（特にXML構成）とは大きく異なり、ほとんどの場合（ジェネリックなどは含まれていません）、構文が異なるVS2003サンプルです。

助言がありますか？ActiveRecordは素晴らしく見えます。

次の要件を考慮して、ORMを活用しようとしています。

1）.NET Frameworkの使用（最新のFrameworkで問題ありません）
2）Sybase、Oracle、MSSQLを互換的に使用できる必要があります
3）スキーマはほとんど静的ですが、動的な部分があります。

私はSubSonicとNHibernateにある程度精通していますが、深くは知りません。
ORMは自分のやりたいことができるというしつこい感じがしますが、今のところそれを活用する方法がわかりません。

SubSonicは現在Sybaseをサポートしていないため、おそらく最適ではありません。独自のプロバイダーを作成することは、現在のところ私のリソースと能力を超えています。

＃3（上記）の場合、ベンダーが既存のデータベースに「固定」できるテーブルを説明するメタデータテーブルがいくつかあります。これらのMetaTablesとMetaFields
を 呼び出しましょう。

ORM（NHibernate ATM）が適切に処理する基本静的スキーマがあります。
ただし、ベンダーは、メタデータテーブルにデータを追加して構造を説明する限り、データベースにテーブルを（物理的に）追加できます。

私が本当に望んでいるのは、ORMにそのメタデータを（理解できる方法で）何らかの形で「フィード」し、その時点でデータを操作できるようにすることです。

私の主な目標は、これらの動的テーブルで実行する必要のある汎用SQLステートメントの作成量を減らすことです。
また、Sybase、Oracle、またはMSSQLに送信されるSQLの違いについて心配する必要はありません。

私の主な問題は、メタデータにアクセスできる実行時まで、動的テーブルについてORMに通知する方法がないことです。

編集：使用法の例は、ここで概説されているようなものかもしれません：

IDataReader rdr = new Query（ "DynamicTable1"）。WHERE（ "ArbitraryId"、2）.ExecuteReader（）;

（ただし、Sybaseプロバイダーがないため、SubSonicが機能するようには見えません（上記を参照）

私は、バックエンドでさまざまな複雑さのデータベースによって駆動される多くの Web アプリケーションを扱っています。通常、ビジネスおよびプレゼンテーション ロジックとは別のORMレイヤーがあります。これにより、ビジネス ロジックの単体テストがかなり簡単になります。個別のモジュールに実装でき、テストに必要なデータはオブジェクトのモックによって偽造できます。

しかし、ORM とデータベース自体のテストには、常に問題と妥協が伴います。

何年にもわたって、私はいくつかの戦略を試してきましたが、完全に満足できるものはありませんでした.

• テスト データベースに既知のデータを読み込みます。ORM に対してテストを実行し、正しいデータが返されることを確認します。ここでの欠点は、テスト DB がアプリケーション データベースのスキーマ変更に対応する必要があり、同期が取れなくなる可能性があることです。また、人工データに依存しており、愚かなユーザー入力によって発生するバグを明らかにしない場合があります。最後に、テスト データベースが小さい場合、インデックスの欠落などの非効率性は明らかになりません。(OK、最後のテストは実際には単体テストを使用する目的ではありませんが、害はありません。)

• 本番データベースのコピーをロードし、それに対してテストします。ここでの問題は、いつでも実動 DB に何が入っているか分からない可能性があることです。時間の経過とともにデータが変更された場合、テストを書き直す必要がある場合があります。

これらの戦略はどちらも特定のデータに依存しており、単体テストでは機能のみをテストする必要があると指摘する人もいます。そのために、私は提案されたのを見てきました：

• モック データベース サーバーを使用し、特定のメソッド呼び出しに対して ORM が正しいクエリを送信していることのみを確認します。

データベース駆動型アプリケーションをテストするためにどのような戦略を使用しましたか? 何があなたにとって最も効果的でしたか?

PHPでORMを作成していますが、基本的にデータベーステーブルに対応するオブジェクトを作成するクラス「ORM」があります（ActiveRecordパターンと同様の/同じ機能を目指しています）。ORM自体は拡張されます。データベース'、データベース接続を設定します。

だから、私は呼び出すことができます：

ORMクラスはこの機能を提供し（クラスプロパティを設定し、save（）、find（）、findAll（）などのメソッドを提供します）、CustomerはORMを拡張します。ただし、将来的には、Customer（または私が作成する他のモデル）にパブリックメソッドを追加したいと思うかもしれません。これでORMを拡張する必要がありますか？

ここではあまり情報を提供していないことは知っていますが、300行以上のコードを投稿するのではなく、漠然とした説明で理解できることを願っています。

頻繁にアクセスされる可能性のある ASPNET MVC アプリケーションのプロジェクトを開始しようとしていますが、DAL に Subsonic を使用することを考えていました。Subsonic が何千もの同時リクエストを処理する能力について、いくつか懸念があります。Subsonic を使用している人気のある Web サイトの例を教えてください。また、NHibernate 以外の Subsonic の代替案について何か提案があれば、それも素晴らしいことです。ありがとう