SharePoint分层体系结构应用程序

Question

创建SharePoint解决方案时，您是否使用企业层体系结构？您能给我一个codeplex.com/其他网站项目，例如我可以找到分层设计的地方吗？ （接口/bl/dal）

Answer 1

我在所有SharePoint解决方案中使用分层体系结构，并将SharePoint通常视为UI层，使其非常薄。任何逻辑都进入业务模型，我有DAL包装器可以抽象列表基础架构（这也有助于测试）。

有关ASP.NET中的分层体系结构的良好阅读，请查看本文 这里. 。它是ASP.NET和NHIBERNATE，但原理是相同的。 .NET中还有一个分层架构样本 这里 在Codeplex上。同样，不是特定于SharePoint，但原则是相同的。

保持SharePoint UI薄，并抵制诱惑，开始阅读/写作到Web Part代码中的列表。像对待数据库一样对待它（因为它是！）

Answer 2

同意比尔。

Web零件，Web控件，应用程序页面等应为UI层，该层呼叫到原始调用上下文不可知的层；呼叫上下文可以是事件接收器，控制台应用程序，计时器作业，工作流程等。始终确保您调用的共享图层对Spcontext.Current不依赖，因为它并不总是存在！接受SPWEB，Splists，Splisitems等作为方法参数和构造函数参数。在网络上下文中，您可以从spcontext.current传递它们，但是在控制台应用程序中，您会自己构造这些。

为了提高调试的易度性（只需按F5）并缩短了开发人员的反馈周期，我经常开始编写一个简单的控制台应用程序，该应用程序将其拨打到包含核心逻辑的图层中，并通过我在控制台应用程序中构建的SPWEB中。核心逻辑完成后，我写了一个薄的WebControl或WebPart来替换控制台应用程序，请从上下文中读取SPWEB，而不是构造它，设置事件处理程序等。

Answer 3

bil和jaap（或其他任何人），

我想知道您在层之间传递的对象/接口类型？您是传递一个splistitem还是传递给代表SplistItem的某种接口？

SharePoint是一个奇怪的野兽，因为用户实际上可以通过Web界面更改数据结构（他们可以在列表中添加/删除/修改列）。如果您传递对象/接口，则每次用户修改列表时，都需要重新编译（并部署）来容纳新列（属性）。如果您传递了SplistItem，则实际上您可以通过直接访问数据源（SharePoint）来打破图层。