At the moment I am in the middle of the analysis phase for a project where the product will be constructed of several (User)Controls that contain certain blocks of functionality, these controls together will create the product.
Our first client needs this product to integrate with SharePoint 2007 (MOSS 2007), but my product manager makes it real clear that at least some of the ‘blocks of functionality’ or ‘components’ need to have the possibility be integrated in existing ASP.NET web applications.
So the challenge I face is creating controls that can be integrated inside SharePoint and custom ASP.NET web apps. Another challenge is that we really want to use the MVP, or MVC pattern, to increase the level of (unit)testability and maintainability.
Also with testability in mind I want to use some kind of IoC container (Inversion of Control), to make it easier to swap out certain functionalities for others (also a Need To Have requirement), be it for unit testing, or swapping out data store's .
Web Client Software Factory
With all these requirements the Web Client Software Factory came to mind, it leverages the Composite Web Application Block and can use Unity (ObjectBuilder) as Dependency Injection or Inversion of Control Container. When I follow the Quick start however it is quite easy to create a webpage that acts as the View and uses a Presenter and a Controller (all interface based!).
The problem I get is when I want to create a UserControl as a View that acts indepentently with it’s own Presenter and Controller, as i am seeing it, the WCSF uses the containing page of a UserControl as the part that maps everything together.
I want to make a really independent control, that can exist all by itself. The learning curve was quite steep, because of my lack of knowledge of the WCSF and CWAB.
I am not sure which route I will take in the end, but I am trying different approaches:
- Using Return of SmartPart to host a UserControl that consists of Usercontrols built using the Web Client Software Factory;
- Create a WebPart (derived from CompositeWeb.SharePoint.Web.UI.WebPart) that hosts UserControls (that are derived from CompositeWeb.SharePoint.Web.UI.UserControl), using the CompositeWeb.Sharepoint.dll and guidance published on the WCSF CodePlex site
For now I created both in a really simple form and find that the SmartPart has a real nice deployment model, you install the SmartPart using a installer and you only have to activate the Smartpart in the SiteCollection to make it available in the available Webpart’s list in SharePoint. You than make a folder with the name ‘usercontrols’ in the root of the sharePoint site, where you put the .ascx files you want to be hosted. The dll belonging to the UserControl and it’s dependencies are to be placed into the bin directory of the same SharePoint site. I read somewhere that the installer sets the site´s security to full trust, but I can not verify that.
WebPart derived from CompositeWeb.SharePoint.Web.UI.WebPart
The Webpart solution gives a real nice compatibility model. You derive from these types and your webpart and UserControls work in SharePoint and in am ASP.NET webapp. This is achieved through the BuildItemWithCurrentContext method in the SPWebClientApplication class (CompositeWeb.SharePoint.dll). This method runs different code depending on the running HttpApplication implementation. You have to manually edit the global.asax file in the root of the SharePoint site. You have to edit the web.config manually to make several changes, one of them is to set the security to full trust! Part of the web.config changes is to add the PublicKeytoken for the webpart in an attribute of the Safecontrol element for the webpart. Furtermore you have to place the assemblies and their dependencies into the bin directory of the Sharepoint site. Of course you could automate these task by creating an installer, but I think it makes clear that there are lots of manual tasks to be done.
At this point in time I have not decided either way, but I will post when I have.
My thoughts exactly…