In most of our latest Sharepoint projects we need a lot of customization. These customization generally mean that we develop webpparts and custom lists so that we use sharepoint as a sort of database. The list itself is rarely visible to end users and only to a extended sharepoint site that is used as a backoffice application.
The development of the webparts go as follows:
-
For every webpart we develop we have:
-
The <webpart>.cs control
-
The <webpart>Control.asc User control
-
The <webpart>.wsp XML file that is used to package the webpart
-
A Test<webpart>.aspx file that is used to test the webpart standalone but is never deployed to the sharepoint application.
-
The webparts do not rely on sharepoint, but bind to strongly type objects and collection.
-
A Provider pattern is used for retrieving and updating of the data objects.
This provider model allows us to test and verify functionality of the webparts without the need to upload/provision these webparts inside a Sharepoint hosted website. We all know this takes a lot of time. The provider is configured in the web.config of the webpart solution file.
Here's a sample of one of these business objects:
public class AppointmentObject
{
private string _description;
public string Description
{
get { return _description; }
set { _description = value; }
}
}
The user control uses this class in codebehind like so:
AppointmentCollection recentAppointments = ServiceProvider.GetRecentAppointments();
RecentAppointments.DataSource = recentAppointment;
RecentAppointments.DataBind();
You see this is basic ASP.Net stuff.
I found this a pretty amazing thing; it cuts down on the time used for each development roundtrip, and it allows us to 'outsource' the development of the web parts to ASP.Net specialist who do not (yet) have the required Sharepoint knowledge. The knife cuts on two sides!
This approach did have an enormous disadvantage however. The provider that implemented the mapping from the hard-coded business object to sharepoint needed a lot of custom code. It only paid of once the business object was used in multiple places. Another problem is that the code that provisioned the custom list was always a one-off piece of custom code. That code has NO relation to the business object.
Now, my experiences with entitypool helped me in writing a library that solves all this:
[SharepointList(Name="Appointments", ShowOnQuickLaunch=true)]
[Description("Appointments"]
public class AppointmentObject
{
private string _description;
[SharepointTextField(Required=true,MaxLength=16)]
public string Description
{
get { return _description; }
set { _description = value; }
}
}
To create the list in Sharepoint, all that is needed is the following statement:
using(SPSite site = new SPSite("http://localhost:90"))
{
SharepointProvisioning.CreateList(site, typeof(AppointmentObject), true);
}
To retrieve all appointmentobjects we have a factory that converts a SPListItemCollection to AppointmentObject objects:
ObjectFactory<AppointmentObject> factory = new ObjectFactory<AppointmentObject>();
AppointmentObject object = factory.GetItem(spListItem);
Easy? I think so.
Currently rated 3.7 by 3 people
- Currently 3.666667/5 Stars.
- 1
- 2
- 3
- 4
- 5