Sharepoint 我应该使用工作流还是事件接收器？

我想构建一个自定义内容类型，它将作为具有多个状态的列表项的基础。各种状态将确定哪个列表将实例化此项。它将根据用户操作在状态和列表之间移动

我有几个选择来实现这一点：

在每个列表上创建工作流，以处理与该列表相关的特定功能。必要时将项目移动到另一个列表（将项目复制到新列表，删除原始项目），然后启动该工作流

在我们将要使用的自定义内容类型上创建一个工作流，并让它在各种列表之间移动项目。不确定内容类型上的工作流是否可以从一个列表移动到另一个列表，更不用说跨网站集了

使用自定义内容类型上的事件接收器来管理状态。用户对一个项目执行操作，更改其状态，因此事件接收器在另一个列表中创建一个自身副本，然后在当前列表中删除自身。我知道这适用于网站集

---

哪条路最好，为什么？有什么绝对不行的吗？任何我忽略的方法？

在我看来，使用事件接收器，因为它们跟随项目而不是列表。您仍然需要为接收列表启用内容类型，但这种方法比基于某些内容类型的存在或不存在来更新和删除列表中的工作流容易得多

然而，为什么不将这些方法结合起来呢？让内容类型事件接收器处理特定于内容类型的活动，并让列表处理任何特定于列表的活动。事件接收器既便宜又灵活

.b一般来说： 在SharePoint中，工作流和事件接收者是相关的（如果查看带有附加工作流的列表上的事件，您将发现启动工作流的事件接收者..）

工作流的优点是用户可以检查日志（假设您使用日志活动）

事件接收者的优势在于事件数量较多；它们比工作流更灵活

---

根据您的描述，我可能会选择工作流，这样用户就可以检查他们的项目处理是否正确。

我使用与每个列表方法相关联的工作流，因为我需要工作流历史记录作为审核跟踪，以便用户做什么。我很喜欢在内容类型上创建工作流的想法，但回顾过去，这将是我所做工作的更清晰的解决方案。

这是一个完美的流程图，用于在工作流和事件接收者之间做出决定：

---

什么可以阻止事件接收者记录事件？没有什么可以阻止事件接收者记录事件-但是，除非您将事件“记录”到用户可以查看的列表中，否则用户将无法查看此日志，对吗？是的，除非您将事件“记录”到用户可以查看的列表中，即“工作流历史”列表，工作流将日志放在哪里。但是比约恩说的是从事件中进行日志记录，它可以记录到windows日志文件、sharepoint列表、数据库或任何您想要的地方。