「Open棟梁 wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
参考 †
- 4章:「D層に関するトピック」も参考にして下さい。
- 7章:「FAQ」> 7.3節：「D層フレームワーク」も参考にして下さい。
パラメタライズド・クエリの初歩 †
- Like検索は標準のパラメタライズド・クエリ、動的パラメタライズド・クエリでサポートされています（パラメタにワイルドカードを含めたLikeの検索条件を渡す）。
- パラメタライズド・クエリのパラメタにnullを渡したい場合、DBNullを使用します（動的パラメタライズド・クエリでは、nullは特殊な制御パラメタとして利用されます）。
方法 †
パラメタライズド・クエリのバインド変数へのバインド方法は？ †
名前バインドにのみ対応しています。このため、どのデータプロバイダであっても、順番バインドをサポートしません。
- ODP.NETのバインドは名前バインド固定になります。
- OLEDB、ODBC、HiRDBのデータプロバイダは
「?」パラメタの順番バインドにのみ対応しているためフレームワーク内部で名前バインド可能になる様に処理を加えています。
なお、制限事項として、コメント中に パラメタ名と同じ文字列があると正しく動作しませんのでご注意ください。
パラメタライズド・クエリのバインド変数への属性指定方法は？ †
- 後工程でのPG修正が難しい場合は、SQL定義ファイル中に型キャストを明示すること型指定可能です。
また、自動生成Daoは型指定するI/Fが無いため、必要に応じて型キャストを使用して対応下さい。
- 自動生成DaoのI/Fでは、パラメタへの属性指定ができないので、自動生成Daoのテンプレート（DaoTemplate?）のSetParametersFromHt?メソッドをカスタマイズすることで、ユーザコードからパラメタへの属性指定がになります。
- そもそも、自動生成ツールで型情報も取得しているので、型込みの生成に対応する
という話もありますが、実装も複雑になるので、現時点では対応を見送っています。
ストアド プロシジャ、無名PL/SQLブロックの実行や、戻り値の取得などは可能か？ †
ストアド プロシジャでも動的パラメタライズド・クエリ機能を使用できます。
ストアド プロシジャの実行方法 †
ストアド プロシジャは、利用ガイドに書かれている方法で実行できます。
現行のCmnDaoでは、
SetSqlByCommand("sp_help", CommandType.StoredProcedure);
のようにStoredProcedure?パラメタが指定できないのでストアド実行はできないと思います。
しかし、現行のCmnDaoも、以下まで対応可能済みなので、
ちょっとカスタマイズすればストアド実行できるようになると思います。
対応されたモジュールをpullrequestして貰えると、とても助かります。
デッドロック、ロックタイムアウト、「ユニークキーの重複」などの例外をリトライしたい。 †
B層ベースクラス2の例外処理をカスタマイズして、 リトライ対象例外を業務例外に振り替え、P層に正常系の戻り値が戻るようにします。
- SetUserParameter()メソッドは、SQLインジェクションの可能性があるものの、DB部品の（僅かな）制約 / 制限などを解決するAPIでもあります。
- このため、SetUserParameter()メソッドの利用を制限せず、D層のベースクラス2に実装するSQLトレースをカスタマイズして
SQLインジェクションの可能性があるSQLをチェック & Warningログを出力するなどの対応をした方がプロジェクトとしては、スムーズに開発を遂行できると考えます。
- D層自動生成ツールでのDao生成時にタイムスタンプ列名を設定し、
タイムスタンプ必須オプションONにして生成することで楽観排他を実現できます。
- 自動生成のDaoクラスを利用しないケースに関しては別途排他に関する実装が必要となりますので、
更新系は自動生成DAOを必ず利用するような運用とすることをお勧めします。
性能 †
コマンド タイムアウト値を設定するにはどうすれば良いか？ †
共通のコマンド タイムアウト値をconfigファイルに設定できます。
ODP.NET、HiRDBの配列バインドをサポートしているか？ †
- サポートしています。
- また、配列バインドをサポートしていないデータプロバイダでの
大量データ処理実装のために、バッチクエリ作成支援機能を提供しています。
SQLで暗黙の型変換が発生し、検索処理性能が大幅に劣化する。 †
- 後工程でのPG修正が難しい場合は、SQL定義ファイル中に型キャストを明示すること型指定可能です。
動的パラメタライズド・クエリを記述するXMLファイルのサイズなどにより性能が劣化しないか？ †
- １つのXMLファイル中に150タグ以上あると性能が劣化が始まりますので、不要なタグは記述しないようにお願いします（XMLファイル サイズについては、問題ないようです）。
- なお、動的パラメタライズド・クエリ分析ツールを使用したテストのために記述する PARAMタグ、DIVタグなどXMLドキュメント オブジェクトの更新処理を伴わないタグについては、性能劣化の原因になりません。
エラー †
動的パラメタライズド・クエリで、[<]、[>]などの文字が含まれると適切に実行されない。 †
XML内部で使用不可能な文字列は、HTMLエンコーディングが必要になります。
これらの文字列が含まれる場合は、下記の現象が発生します。
- DB部品の最も初めのチェック処理にXmlDocument?.Load()メソッドを使用しているため、
として実行されるため、この現象は、不正なフォーマットのXMLを投げている事に起因します。
して下さい。
自動生成Daoの Update処理で「ORA-00972 "識別子が長すぎます"」が発生する。 †
- D層自動生成ツールは、Update時に使用するパラメタ識別子に
１文字以上のプレフィックス・サフィックスを追加する必要があります。
- この際、パラメタ識別子が30文字を越えてしまい、エラーが発生するケースがあります。
- この再設定と、再生成が面倒な場合は、文字列一括置換ツールなどを使ってパラメタ識別子を
置換するなどして下さい（DaoとUpdate処理のSQL定義（XML）が置換対象ファイルになります）。
検索条件のIN句（副問合せ）を動的化したいがエラーとなる。 †
検索条件のIN句（副問合せ）を動的化する場合、動的パラメタライズド・クエリのIFタグ ではなく、タグのネストが可能なSUBタグを使用頂けます。
Daoの使い分け †
更新系処理 †
自動生成Dao
単一テーブルからのSELECT †
自動生成Dao
複数テーブルなど複雑なSELECT †
共通Dao(CmnDao)
大量データ処理（バッチ更新処理） †
大量データ処理（バッチ更新処理）で
性能が出ません。
従って、大量データ処理（バッチ更新処理）の場合は、
を使用して下さい。
制限事項 †
- 動的パラメタライズド・クエリのパラメタで、
XMLタグの編集処理に使用されるパラメタ（タグ内パラメタ）の
パラメタ名は、（同じ値を使用するパラメタであっても、）
別々に（１つのXMLタグ毎、ユニークに）定義する必要があります。
アルゴリズム †
含むXMLタグを「再帰的」に検索し、
- パラメタ設定されていれば、
- テキスト内パラメタのあるXMLタグを有効化
- タグ内パラメタのあるXMLタグを有効化（その際、パラメタは消す）
としています。
結論 †
XMLタグの検索方法が再帰的なので、
- タグ内パラメタに同じパラメタがあっても、
パラメタを消す・消さないの判断がつきません。
- しかし、テキスト内パラメタであれば、
パラメタを消さないので、同一名称のパラメタも付与できます。
<?xml version="1.0"?>
<ROOT>
SELECT * FROM Shippers
<WHERE>
WHERE
<IF>ShipperID =@P1<ELSE>IS NULL</ELSE></IF>
<IF>and ShipperID =@P1<ELSE>IS NULL</ELSE></IF>
</WHERE>
<PARAM>
P1, Int32, 1<DIV/>
</PARAM>
</ROOT>
↓↓↓
SELECT * FROM Shippers
WHERE
ShipperID =@p1 and ShipperID =@p1
サポート †
Like句を使用した曖昧検索をサポートしているか？ †
- サポートしています。
- パラメタライズド・クエリ自体がLike句を使用した曖昧検索をサポートしているため文字列連結やSetUserParameter()メソッドを使用する必要はありません。
LINQ to SQLやLINQ to Oracle、LINQ to Entities（ADO.NET Entity Framework）をサポートしているか？ †
任意のDLL（Assembly）からの埋込SQLのロードをサポートしているか？ †
- ベースクラス2のSetSqlByFile2メソッドを用いてExecutingAssembly?の埋込リソースから SQLをロードすることができますが、
任意のDLL（Assembly）から埋込リソースをロードを行う場合は、SetSqlByFile2メソッドのカスタマイズが必要になります。
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
