2008-12-18 80 views
2

我在Sharepoint和Project Server上開發了一個相當大的項目,它被設計爲一個多層應用程序。我以編程方式管理某些Web部件頁面上的Web部件。根據用戶在其中一個網頁中的選擇,將適當的網頁部分添加到另一個網頁部分頁面的網頁部分集合中。我的問題是,我根本不知道在哪裏管理Web部件,我應該在BLL中執行它,然後讓包含業務邏輯的程序集引用Web部件所在的UI組件? (因爲我不想使用表示Web部件dwp的硬編碼字符串,所以我需要在將Web部件添加到集合時實例化Web部件。)Sharepoint Web部件管理

+0

你可以使用依賴注入來解決這個問題問題? – 2008-12-18 10:59:11

回答

0

這真的取決於你所使用的模式爲您的BLL和UI層,以及如何嚴格要遵循它。

如果你正在做一個MVP模式,那麼我建議你有Page實施具有下列選項中的一個(或多個)的接口:

  • 一疊Presenters加載哪些被添加到
  • Load_ WebPartName事件爲需要在裝載

要然後應該調用以指示哪些web部件(一個或多個)的每個Web部分嚴格MVP你應該引用您的BLL項目中的以下組件:

  • 的System.Web
  • 微軟。的SharePoint
  • Microsoft.SharePoint程序。*

(所有SharePoint組件將在任何模型或UI項目,BLL只是連接到相應的跗關節)

0

可以將Web部件打包爲一個或一組功能,並且那麼只需通過Web部件管理器類來管理功能激活/停用?

需要適當的Web部件頁可以在功能接收處理上發生的Web部件的任何編程按摩,讓你的經理不需要那麼瞭解Web部件的UI。

HTH, JT

0

Web部件正在使用的功能/解決方案框架通常最好的管理。您可以將您編寫的webpart類作爲任何其他web控件處理,從而作爲ui層的一部分。我通常會將xml文件(.webpart或.aspx文件)中的信息保持在最低限度。如果你只管理它們,你根本不需要使用聲明性代碼文件。

簡短的回答:的webpart是SharePoint專用UI,並且應該沒有業務層的知識。

0

簡短的回答可能是「不,你不應該在BLL做到這一點。」純粹主義者可能會爭辯說,雖然BLL可以正確地確定用戶可以做什麼或不可以做什麼,但是由UI層決定合適的Web部件將作爲結果顯示。例如,BLL可以確定用戶的能力並將它們暴露爲角色或權限或具有域相關含義的其他內容(例如時間表批准者角色,批准時間表權限等)。這些可能會被映射到UI層的一組Web部件(例如時間表批准Web部件)。通過這種方式,BLL可以有效地確定用戶的功能,UI層爲這些功能確定UI。