SharePoint 2010 - 最佳实践：如何处理组件[讨论]

Question

在进行 SharePoint 编程时，有一个讨论已经持续了好几年了。

在 Visual Studio 中，您可以添加 SharePoint 解决方案，该解决方案将转换为 .wsp 文件以进行部署。此 .wsp 文件将包含所有必需的程序集文件。

你们如何处理以下代码隐藏文件：事件接收器、功能接收器、aspx 页面？

您是否将此 .cs 文件放置在您的 SharePoint 文件夹中？（这样您还需要从 SharePoint 项目部署 .dll）

或者您是否将所有代码逻辑移至一个（或多个）不同的项目（类库）？

例如，您在第二个示例中所做的事情：

• 右键单击，添加新项目，事件接收器
• 将 .cs 文件移动到不同的项目
• 更改 Elements.xml 文件内的程序集信息

在第一个示例中，我们不移动这些文件，只是在 VS2010 添加它们时保留它们。

我并不是说我喜欢哪种方式，我只是想收到很多意见。不要只说“选项2不好”。我真的想知道为什么和为什么不！

谢谢

编辑：

我的问题与扩展等无关。

我说的是确保您的共享点解决方案不包含任何 .cs 文件。这样，GAC 中就不必为该解决方案召开大会。

例子：我有 Customer.SPS.Intranet.Solution（=生成 WSP 的解决方案，因此是一个空的 SharePoint 项目项）。

如果我只是添加一个功能和一个功能接收器，则会生成一个 .cs 文件，并且（部署后）Customer.SPS.Intranet.Solution.dll 文件会放置在全局程序集缓存中。

这是有些人不愿意拥有的！！！（我不明白为什么，所以我才问一些意见）。

为了解决这个问题，他们在这个解决方案中创建了一个项目，名为：“Customer.SPS.Intranet.Logic”，该解决方案将包含所有功能接收器代码隐藏文件。

这意味着我们必须编辑功能 template.xml 文件才能使用位于“Logic”项目中的接收器类。这样我们就可以保持“Customer.SPS.Intranet.Solution”的干净，并且只将其用于打包。因此，不会有名为“Customer.SPS.Intranet.Solution.dll”的程序集部署到 GAC...相反，Customer.SPS.Intranet.Logic.dll 程序集被部署到 GAC。

Answer 1

啊啊，解决方案和 dll 的永恒问题。:-) 为什么分手，为什么不分手，什么时候分手？我不在自动提款机工作，我在度假，但当你让我看一下时，我将总结一些外卖和我的看法。所以我的回答是基于个人的经历和看法。（对不起，StackExchange）

x 不拆分“代码隐藏”和 UI 会导致代码难以维护。我在不同的项目中看到的是，缺乏经验的开发人员不能很好地处理“背后代码”（XML/ASPX 旁边的 C# 类）。他们倾向于将更多逻辑写入背后代码，因为他们可以直接访问 UI。在一个特定的项目中，我看到一个 1500 行的“新”页面（这已经很大了），而“编辑”页面基本上是新页面的复制和粘贴。当然，这是“糟糕的编程”，将代码放在工件旁边并不是固有的。但坏习惯很难改变，这种工作模式可能会让事情变得更糟。在这种情况下，首先将 cs 类作为控件，并为编辑类提供某种继承类，这样会更容易维护。创建后，您可以使您的 asps 页面继承这些类。

x 不拆分“代码隐藏”和 UI 会导致类具有太多逻辑。该项目的另一件事是新页面作为编辑页面都直接连接到外部 SQL 数据库。他们使用直接 SQL 连接，这会增加代码和维护的开销。分层方法会有很大帮助。

x 分层应用程序需要单独的程序集。嗯，分层很好！您需要单独组装它吗？不必要。您可以将逻辑、数据访问层等分组到程序集中的单独文件夹/命名空间中。这些也是层。“但是我为什么要把它们分开呢？”这往往是好习惯。为什么？那么您可以避免意外使用更深层的逻辑（例如 SQL 连接），因为该逻辑仅在 DA 层中引用。另一个优点是用另一层替换顶层可能更容易。比如说另一个用户界面或移动界面。您可以进一步推动它并使较低层更加通用，以便您以后可以重复使用它们。这就是创建 nHibernate 和 EF 框架的方式。

X“很好，但这只是ASP.NET的开发。”是的，但是在开发SharePoint工件（如接收器）时，可以使用相同的原则和想法。为什么不努力开发可以使用功能属性或文件夹属性进行参数化的通用接收器呢？重用逻辑通常会产生更稳定的解决方案。

x 分离鼓励（单元）测试。一旦开始分离和创建更通用的类等，使用接口和模型就不再是一个漫长的过程。这意味着单元测试将更容易实现（尽管我们实际上应该使用 TDD），因为我们可以更轻松地进行模拟。查看 MVC 框架以及其中的各个部分是如何很好地分离的。这也适用于 SharePoint。

因此，总结一下我的 2c（以及更改；-)），您可以直接使用后面的代码来构建您的工件，但我不喜欢这样做。我宁愿选择重用、通用和可测试的代码，也不愿将接收器和代码自动匹配到工件（尽管您不需要在手动情况下更改功能模板 XML，因为您只需在属性中添加功能接收器）并且易于定位（我使用 VS2010 的即时转到）但最终这完全取决于您和您的项目的偏好。:-)

Answer 2

实际上，就我个人而言，从未遇到过将 SharePoint 解决方案中的文件移出项目的解决方案，除非您已经确定了可重用部分的情况：例如扩展方法，基本事件处理程序代码。还有一个不将其移出的原因，例如通常VS 2010使用GUID来装饰类以在其连接处理程序上进行内部工作，因此它可以正确地构建依赖关系。此外，所有二进制文件都是内置的，因此 code-beside（SP2010 中不再有代码隐藏）已经是内置的。除了注册 SafeControls（Web 部件、自定义控件等）之外，还无法正确注册，因为 Visual Studio 可以将外部程序集包含到您的包中，但他不一定会搜索这些程序集以获取实际代码 - 您需要执行所有这些操作手动 - 不利于生产力。

这些是初步的思考，可能会带来更多的思考，但基本规则是：您不会重复使用这些部分 - 那么最好将它们留在 VS 建议的地方。而是提前计划您部署的功能类型、您拥有的依赖项、功能范围、激活顺序等。

希望它有帮助，c： marius