多層アプリケーションとして設計された、Sharepoint と Project Server で開発されたかなり大規模なプロジェクトがあります。特定の Web パーツ ページの Web パーツをプログラムで管理しています。いずれかの Web ページでのユーザーの選択に従って、適切な Web パーツが別の Web パーツ ページの Web パーツ コレクションに追加されます。私の問題は、Web パーツを管理する場所がわからないことです。BLL で管理し、ビジネス ロジックを含むアセンブリで Web パーツがある UI アセンブリを参照する必要がありますか? (Web パーツ dwp を表すハードコードされた文字列を使用したくないため、Web パーツをコレクションに追加するときにインスタンス化する必要があります。)
1303 次
4 に答える
0
簡単な答えはおそらく「いいえ、BLLでこれを行うべきではありません」です。純粋主義者は、BLLがユーザーができること、できないことを正しく判断できる一方で、結果として表示される適切なWebパーツを判断するのはUI層次第であると主張するかもしれません。
たとえば、BLLはユーザーの機能を決定し、それらを役割、アクセス許可、またはドメイン関連の意味を持つ他の何か（たとえば、タイムシート承認者の役割、タイムシート許可の承認など）として公開する場合があります。これらは、UI層によって一連のWebパーツ（タイムシート承認Webパーツなど）にマップされる場合があります。このようにして、BLLはユーザーの機能を効果的に決定し、UI層はそれらの機能のUIを決定します。
于 2008-12-29T04:10:35.643 に答える
0
Web パーツを機能または機能セットとしてパッケージ化し、Web パーツ マネージャー クラスを介して機能のアクティブ化/非アクティブ化を簡単に管理できますか?
適切な Web パーツ ページで実行する必要がある Web パーツのプログラムによるマッサージは、フィーチャー レシーバーで処理できるため、管理者は Web パーツの UI をそれほど意識する必要はありません。
HTH、jt
于 2008-12-22T18:03:57.917 に答える
0
それは、BLL および UI レイヤーに使用しているパターンと、それにどれだけ厳密に従うかによって大きく異なります。
PageMVP パターンを実行している場合は、次のオプションの 1 つ (または複数) を持つインターフェイスを実装することをお勧めします。
Presentersロードする が追加されるスタック- どの Web パーツをロードする必要があるかを示すために呼び出す必要がある各 Web パーツのLoad_イベント
WebPartName
厳密に MVP になるには、BLL プロジェクトで次のアセンブリを参照しないでください。
- System.Web
- Microsoft.SharePoint
- Microsoft.SharePoint.*
(すべての SharePoint アセンブリはモデル プロジェクトまたは UI プロジェクトのいずれかにあり、BLL は適切なホックに接続しているだけです)
于 2008-12-29T04:58:03.333 に答える
0
一般に、Web パーツは機能/ソリューション フレームワークを使用して管理するのが最適です。作成した Web パーツ クラスを他の Web コントロールとして扱うことができるため、UI レイヤーの一部として扱うことができます。私は通常、xml ファイル (.webpart または .aspx ファイル) 内の情報を最小限に抑えます。それらを排他的に管理している場合は、宣言型コード ファイルを使用する必要はまったくありません。
簡単に言えば、Web パーツは SharePoint 固有の UI であり、ビジネス レイヤーについての知識は必要ありません。
于 2008-12-26T17:04:09.563 に答える