我想子类化一些SharePoint对象,例如SPSite,SPWeb,SPList和SPListItem。知道怎么做吗?我无法创建派生类的实例,因为我无法使用构造函数构造对象。
我通常使用容器类来包装所述对象,但我不认为这是一个很好的解决方案,因为它不能为对象提供良好的语义和OOP感觉。任何帮助或建议都表示赞赏。
感谢。
答案 0 :(得分:8)
我建议不要对SharePoint对象进行子类化,因为我没有看到任何用途。如果要将SharePoint对象子类化为添加或覆盖几个方法,请尝试使用.NET 3.5的扩展方法。这应该对你有帮助。
答案 1 :(得分:0)
这是正确的,我想派生标准的SharePoint对象并扩展它以添加我自己的方法和字段。例如,我有一个名为Order的自定义列表定义。而不是像程序那样:
SPListItem item = new SPListItem();
item["Title"] = "Transformers DVD";
item["Price"] = 30.5;
item["Qty"] = 2;
item.Update();
The OOP-way should be done like this:
Order order = new Order("Transformers Movie", 30.5);
order.SetQuantity(2);
order.Save();
类似的东西。
答案 2 :(得分:0)
那么我会查看类似于表中的行的SPListItem而不是实体。为了将数据推送到数据库,我们将有一个数据库层来处理所有与数据库相关的东西,并通过实体传递数据。上面的代码可以重写如下。
class Order{
public int Price {get;set;};
public int Qty {get;set;};
public String ItemName {get;set;};}
class OrderHandler{
Order m_Order=null;
public OrderHandler(Order oEntity)
{
m_Order=oEntity;
}
public void Insert(){
SPListItem item = new SPListItem();
item["Title"] = m_Order.ItemName;
item["Price"] = m_Order.Price.ToString();
item["Qty"] = m_Order.Qty.ToString();
item.Update();
}
}
我很确定这没有错。
答案 3 :(得分:0)
我同意其他海报的观点,即对SharePoint对象模型中的类型进行子类化是一个坏主意。我这样做的最大原因是:
处置问题可能是最大的威慑力量。
继承并不总是坚持OO原则的最佳解决方案。在维护方面,对象层次结构也存在缺点。
听起来你已经探索过封装,这是一种非常有效的面向对象方法,并且优于继承(在我看来):
public class Order {
private SPListItem listItem;
...
public Order(SPListItem listItem) {
this.listItem = listItem;
}
...
public int ItemName {
get { return listItem["Title"] as string }
set { listItem["Title"] = value; }
}
...
}
这些方法(继承和封装)的一个问题是它们将对象耦合到底层数据存储(在本例中为SharePoint)。根据你想要设计的内容,这可能是也可能不是坏事。
另一种方法是将代码与底层存储分开,并使用存储库来处理获取和更新存储库中的对象。至少与SharePoint的任何耦合都可以由单个存储库类型处理,您可以在其周围放置一个接口,以允许您使用其他存储库(用于将来的方案或用于测试)。
这一切都取决于您的使用案例以及您的代码和平台将来可能会发生多大变化。
一种不错的轻量级方法是Chris O'Brien's blog (Simple data access pattern for SharePoint lists)。如果您的需求与他的需求相符,那么这是一种实用的方法。