問題タブ [enterprise-library]

検証 (Enterprise Library Validation Block を使用) を配置するのに最適な場所がどこにあるかわかりません。それはクラス上にあるべきですか、それともインターフェース上にあるべきですか?

影響を与える可能性のあるもの

• インターフェイスから継承するクラスでは、検証規則は変更されません。
• クラスを継承するクラスでは、検証規則は変更されません。
• ほとんどの場合、クラスから継承が行われます - インターフェイスから継承する特殊なケースがいくつかあると思います (しかし、私はそれを避けようとします)。
• インターフェイスの主な用途は、Unity ブロックで行われる DI です。

int などの null 許容プロパティの検証を考え出そうとしています。

例

ただし、Agenull に設定した場合、範囲内にないために検証が失敗します。[ValidatorComposition(CompositionType.Or)]同様に必要であることはわかっていますが、他に何を使用すればよいでしょうか?

I was wondering what were the hidden performance implications of using the Database object in the Enterprise Library. I have an OleDbCommand (type=stored procedue) that is calling an IBM iSeries stored procedure that is taking anywhere from 1.5 to 4.5 minutes to complete.

If I manually run the sproc using the iSeries tools and similar parameters then it takes about 5 secs. So the performance slowdown is either in the network communication to the iSeries or something hidden within the Database object within the Enterprise library. Just looking for any ideas.

AzMan XMLストアの相対接続文字列を指定することは可能ですか？

私の現在の接続文字列はですconnectionString="msxml://c:/azman.xml"が、他の開発者や自動ビルドが最新の認証ストアを取得できるように、実際に相対的なものにする必要があります。

MSのドキュメントは、それが機能するはずだと示唆しているようですが、それはエラーconnectionString="msxml://azman.xml"をスローしThe request is not supportedます。

編集：エンタープライズライブラリセキュリティアプリケーションブロックを介してAzManを使用しているという事実が質問にとって重要であることに気づきました。

int に解析された後、値がオブジェクトの int プロパティに渡される TextBox があります。

ValidationProvider を使用すると、検証時にこの変換手順が無視され、文字列を int32 に保存できないというエラーが表示されます。

フォームのテキスト ボックス値とビジネス オブジェクトの int 値の間のブリッジとして機能する文字列プロパティをオブジェクトに作成することでこれを修正できますが、検証レイヤーを満足させるためにドメイン オブジェクトを変更する必要があるため、このアプローチは嫌いです。 .

ドメインオブジェクトにブリッジプロパティを作成せずに、変換後に値を int に格納するテキストボックスを検証するにはどうすればよいですか?

私が現在取り組んでいるプロジェクトでは、ロギングに Enterprise Libraries V3.1 フレームワークを使用しています。

生成されたログ ファイルを特定の時点でアーカイブする必要があります。組み込みの Trace Listener は、ロギング イベント間でファイルを開いたままにしているようです。ファイルに追加して閉じるカスタム トレース リスナーをセットアップし、ファイルが常にシフト可能になるようにしました。

次のようになります (わかりやすくするためにエラー処理を省略しています)。

これは問題なく動作しますが、パスをハードコーディングするのではなく、何らかの方法でパラメーターとして渡したいと思います。

楽しみのために、コンストラクターに追加して、何が起こるかを確認してみました。

これを行うと、何が間違っているかを示唆するエラーメッセージが返されます。

ここから先、私の調査は行き止まりとは正反対の、無限の確率の問題に行き着きました。

組み込みのソースコードからこの親指を見つけましたRollingTraceListener

• RollingFlatFileTraceListenerData : TraceListenerDataコンストラクターに渡されたすべての設定を含むと思われるクラスがあります
• ファイルの下部にキャンプアウトされているのは、工場と思われるRollingFlatFileTraceListenerDataクラスですRollingTraceListenerAssembler : TraceListenerAsssembler
• クラスを構成アプリケーションに提示可能にSystemDiagnosticsTraceListenerNode : TraceListenerNodeするように見える別のクラスがありますData

CustomTraceListener私の質問はこれです:の構成可能なパラメーターを使用して を作成するにはどうすればよいpathですか?

アプリケーションのログインに log4netor エンタープライズ ライブラリ ログ アプリケーション ブロック (LAB) を使用することの長所と短所を理解しようとしています。LAB は log4net よりも少し使いにくいことが 1 つあります。

The Microsoft Enterprise Library の Exception Handling Application Block の最新バージョン (4.1、2008 年 10 月リリース) には、2 つの HandleException() メソッド シグネチャがあり、これらの意図が少しわかりません。も、QuickStart アプリも意味のある違いを暗示していません。

以下に 2 つの署名を示します。

私が見つけたすべての例は、最初の例を使用しています。この例では、実際のメソッドに関する XML ドキュメントのコメントから直接引用しています。

同じソース (メソッドの XML ドキュメント コメント) から、2 番目の使用例を次に示します。

ですから、私の質問は、最初のものでは得られないもので、2 番目のものを使用すると何が得られるのでしょうか? これはおそらく私には明らかなはずですが、今日の私の頭は混乱しており、ことわざの壁に頭をぶつけ続けたくありません. :)

憶測はご遠慮ください。これを使用した経験から、彼らが何を話しているのかを実際に知っている人からの連絡をお待ちしています.

Enterprise Library を使用して SQL サーバーへの接続を管理する 3 年前の Windows サービス (C# .Net 1.1) をサポートしています。このサービスは受信メッセージを監視し、メッセージに応じてさまざまなタスクを実行します。そのほとんどはデータベースの更新を伴います。私の知る限り、このサービスはシングル スレッドであり、一度に 1 つずつキューからメッセージを読み取ります。

ここ数日で、ランダムに「壊れる」のを数回見ました（前回は昨夜の真夜中頃）。この間、DB へのすべての更新ではなく一部の更新が失敗し (約 20% 程度)、イベント ログに多数の警告が表示され、ファイル ログにエラーが記録されます (以下に再現)。サービスを再起動すると、すべてが再び完全に機能します。

おそらく、Enterprise Library の接続プールと関係があるのではないでしょうか? Enterprise ライブラリが、DB サーバーが許可するよりも多くの接続のプールを維持しようとしている可能性はありますか? しかし、なぜそれが失敗するのか、なぜもう少しうまく失敗しないのかわかりません。

これらの失敗の本当の理由について、エンタープライズ ライブラリのログ記録からもう少し情報を得る方法はありますか?

イベントログの警告は次のようになります: (少し編集)

同時に、サービスから呼び出されたときに、エンタープライズ ライブラリからの Null 参照例外がエラー ログ ファイルに表示されます。

以前 (以前の「壊れた」段階で)、次のような例外が見られました: (もう一度、恥ずかしがり屋に少し編集しました!) これが、接続プーリングに問題があると思わせた理由です。これは、コードが（エラーではない）アクティビティをDBに記録する場所だと思いますが、エンタープライズライブラリコードはDBへの接続を再度取得できません（常に前述の「データ接続を開けませんでした」というエラーと相まって.

ヘルプ、特にログからより多くの情報を取得するためのポインターは大歓迎です。

その他の背景情報: Windows サービスは C# .Net 1.1 で記述されており、Windows Server 2003 ボックス上で、ドメイン アカウント (必要な DB に対するすべての適切なアクセス許可を持っています) の下で実行されます。DB サーバーは SQL 2005 であり、Windows Server 2008 で 2000 互換モード (Yay legacy!) で実行されています。