ASP.NET/VB.NET アプリケーションで ApplicationBlocks ( Microsoft アプリケーション ブロックの紹介と概要 )を使用する際の制限は何ですか? データ層を Web 層から分離するなどのメリットについて説明している Web サイトをたくさん見つけましたが、制限について説明している Web ページを見つけることができません。
質問する
207 次
1 に答える
0
短所の簡単なリストを実際に取得できるとは思いません。Microsoft Enterprise Library は優れたライブラリであり、十分に文書化されており、豊富な機能を備えています。
質問を「使用する必要がない場合は? 」に変更する必要があります。もちろん、この質問はブロックごとに繰り返す必要があります。少しまとめてみます。
すべてのブロックについて、複雑さが必要ない場合はライブラリを使用しないことを検討する必要があります。機能にはコストがかかりますが、最も明白なのは複雑さです(最初は展開と構成)。文書化する必要があり、ユーザーがアプリケーションの構成を変更する必要がある場合は、何らかのツールまたは多くの文書を提供する必要がある場合があります。複雑さはコードにも隠されている可能性があります.EL デザイナーがすべてを簡単にしようとしても、生のソリューションほど簡単にはなりません.
2 番目の重要な欠点は、明らかに速度です。抽象化のレイヤーは無料ではあり得ません。そのための速度コストを支払う必要があります。気にしない場合もありますが (単純なロギングなど)、問題になる場合もあります (したがって、答えは「場合による」です)。たとえば、Unity Application Block について考えてみてください。インジェクションのすべての機能を利用できますが、これには多大なコストがかかります。
では、いつ使用する必要がありますか？私の意見では、このライブラリの大きな目標は、すべてを一緒に使用する必要がないことです。必要なときに必要なブロックを選択できます。たとえば、ロギングや例外処理を使用することは非常に一般的ですが、生涯にわたって Unity を必要としない場合もあります。データ アクセス アプリケーション ブロックは ADO の上にある非常に薄いレイヤーであり、多くの一般的なタスクを簡素化しますが、たとえば LINQ to SQL やエンティティを使用すると、抽象化のレベルを得ることができません (これらの目的が非常に異なることを忘れないでください)。 ）、他のすべてが必要なものに合わない場合にのみ、それを使用することを検討する必要があります.
最後に、私の意見では、各ブロックを検討し、エンタープライズ レベルのライブラリに伴うすべての複雑さが本当に必要な場合にのみ、それを使用する必要があります。小規模なシングル ユーザー アプリケーション用には設計されていません (特定のタスクに適したアプリケーション ブロックがいくつかある場合でも)。その欠点は少なくありません。複雑さと速度は無視できません (短期的なソリューションと長期的な保守計画の両方で)。さらに、そのすべての機能が本当に必要な場合は、「すぐに使える」ソリューションほど簡単ではないことがわかります。制御するには、より多くのコードを記述する必要があります。
于 2012-10-17T20:10:35.580 に答える