* *Clarification. Application == Site Definition. Direct Database access is out the window ** I've created an application for SharePoint that utilizes some new approaches to coding List Access. I've structured things in a way that allows me to control data interaction in a precise manner.
For example, I have a class called Post, which has some typical metadata like Title, Summary, etc...
Inside Post is a static method called NewPost which returns a pre-formatted SPListItem for use in creating new posts.
public static SPListItem NewPost(string Title,string Summary)
{
Posts = CoreLists.Posts();
var item = Posts.AddItem();
var item["Alias"] = SPContext.Current.Web.CurrentUser.LoginName;
return item;
}
You'll notice I'm getting the SPList through a helper class called CoreLists
public static class CoreLists
{
public static SPList Posts()
{
return SPContext.Current.Web.GetList(SPContext.Current.Web.ServerRelativeUrl + "/lists/Posts");
}
}
This makes for some nice clean data methods. What I'm running in to, is that I cannot find a decent way to call these methods with SPSecurity.RunWithElevatedPrivileges
SPSecurity.RunWithElevatedPrivileges
cannot function with a return block, so when I try to create a new list item, it fails every time.
I'm doing this because I'm making my lists hidden. I want people to only access them through the UI I'm creating. I want to further lock the system down from URL hacking by allowing only admins to create items, and use SecurityBits to lock down item editing only to the creators of list items.
Therefore, all List Items are created by System Account, and then they have a field called Alias which allows me to match the item to a user.
Do I need to rethink my entire Data Access Layer? Does the decision to restrict List Access conflict absolutely with the desire for a cleaner Data Access Layer?