Sharepoint Web Part Management

Question

I have a rather large project developed on Sharepoint and Project Server, designed as a multi-tier application. I programmatically manage web parts on certain web part pages. According to the choices of the user in one of the web pages, appropriate web parts are added to the web part collection of another web part page. My problem is that I simply do no know where to manage the web parts, should I do it in the BLL and then have the assembly containing the business logic reference the UI assembly where the web parts are? (I need to instantiate the web parts when adding them to the collection, since I do not want to use hard coded strings representing the web part dwp.)

Answer 1

Can you package the web parts as a feature or set of features and then simply manage the feature(s) activation/deactivation through the web part manager class?

Any programmatic massaging of the web part that needs to happen on the appropriate web part page can be handled in the feature receiver, so your manager doesn't need to be so aware of the web part UI.

HTH, jt

Answer 2

Web parts are generally best managed using the feature/solution framework. You may treat the webpart classes you write as any other web control, and thus a part of the ui layer. I generally keep the information in the xml files (the .webpart or .aspx files) to a minimum. If you are managing them exclusively, you don't really need to use declarative code files at all.

The short answer: webparts are sharepoint specific ui, and should have no knowledge of the business layer.

Answer 3

The short answer is probably "no, you should not do this in the BLL." A purist might argue that while the BLL may rightfully determine what a user can or can't do, it is up to the UI tier to determine the appropriate web parts to be displayed as a result.

For example, the BLL might determine a user's capabilities and expose them as roles, or permissions or something else with domain-related meaning (e.g. timesheet approver role, approve timesheet permission, etc.). These might then be mapped to a set of web parts by the UI tier (e.g. timesheet approval web part). In this way, the BLL effectively determines the users capabilities and the UI tier determines the UI for those capabilities.

Answer 4

It really depends on what pattern you're using for your BLL and UI layers, and how strictly you want to follow it.

If you're doing a MVP pattern then I'd suggest that you have the Page implementing an interface which has one (or more) of the following options:

• A stack which the Presenters to load are added to
• A Load_WebPartName event for each web part which then should be called to indicate which webpart(s) need loading

To be strictly MVP you should not reference the following assemblies in your BLL project:

• System.Web
• Microsoft.SharePoint
• Microsoft.SharePoint.*

(All SharePoint assemblies would be in either the Model or UI projects, the BLL is just connecting to the appropriate hocks)