内容类型与自定义列表字段

Question

这是关于最佳实践和SharePoint设计师的意图的问题。

我对SharePoint的新手很新，并且只从事非常小的项目。我经常发现自己创建自定义列表和库。在此特定实例中，我有一个文档库，我的用户将使用该库来协作编辑和验证大量Excel电子表格的内容。我有一个单独的列表，该列表使用事件处理程序跟踪对第一个列表中元素的更改。

当我进行此类工作时，我通常只创建一个自定义列表或自定义文档库，其中使用“创建列”菜单选项添加列。我几乎从不使用预先存在的内容类型的字段。我偶尔为整个列表创建了一种自定义内容类型，但是整个过程似乎比需要更复杂和维护。但是，我假设我在这里没有看到与可伸缩性或可重复使用性有关的问题。这甚至是一个相关的问题吗？

• 是否有任何令人信服的理由如何使用内容类型/站点列代替本地自定义列表字段？
• 是否有任何令人信服的原因为什么应使用本地，自定义列表字段而不是内容类型/站点列？
• 例如，避免使用标准的SharePoint列表类型，而是创建一个存储几乎相同信息的自定义列表，是否有更深层次的问题更深入的功能重复？

Answer 1

内容类型的设计意图是支持重复使用列表模式（或行为）。因此，如果需要创建许多具有相同结构的列表（通常是这种情况），那么内容类型可以实现这一目标。在这种情况下必须单独创建列表架构并将导致重复性错误的工作是不可接受的。通常在大型SharePoint站点中，需要在元数据中执行某种水平的一致性。

如果您只创建一个列表，并且您预计不会在网站其他地方构建类似列表，则没有理由使用内容类型。您只需创建一个临时自定义列表即可。在要在不同的内容类型和列表上创建一致的元数据的情况下，字段 - 站点列也很有用，但是如果您没有该要求，则不是必需的。

如果对您的自定义列表有意义，则标准列表类型是一个有用的起点。例如，链接列表为您提供了一些额外的功能，因此，如果您的功能更复杂，但是，它的核心是超链接的列表，这是一个很好的起点。但是，如果您不需要这个自定义列表，则没有错。

Answer 2

比尔（@spdoctor）说了什么。这取决于。

与＃3相关，随着您使用的解决方案变得更大，您将倾向于将解决方案分配在几个站点集合中。由于内容类型具有站点收集范围，因此，如果您不想对内容类型进行冗余维护，这可能会成为问题。

为了解决此问题，您可以使用新的SP2010功能，内容类型中心。 CT集线器是内容类型的托管画廊，可让您在网站集合中发布内容类型。

阅读更多 这里.

Answer 3

我总是创建站点列和内容类型。 Harsh的经历告诉我，某人可能将任何实施的东西都视为一个很酷的想法，并要求将其在同一站点集合中的其他地方实施。

如果您在网站内部的多个列表中使用中的内容类型的层次结构，并且更改请求意味着您需要在所有情况下必须在所有情况下添加选择列，则需要在所有情况下繁殖，您可以轻松地使用内容类型。

请求要求您将选择添加到仅使用该内容类型的一个列表中？同样，由于“列表内容类型”实际上是站点内容类型的实例（尽管它们确实从站点内容类型继承）。

Answer 4

第一个问题 - 是的。在许多地方，一些数据很常见。例如，您可能有一个“财务季度”的站点专栏，并且可以在许多地方使用。无论是费用请求还是某种报告，财务季度仍然是财务季度，因此能够在类型之间共享该列是有意义的。从概念上讲，这是同一件事。

同样，内容类型可能适用于多个位置。例如，无论是在“销售”团队网站还是“工程”网站中，“旅行费用”文档内容类型是同一件事。通过使其具有相同的内容类型，您可以通过其中的所有内容找到所有内容。然后，您可以轻松搜索所有旅行费用（有几种方法可以这样做）

关于为什么使用本地字段或内容类型（第二个问题） - 有时候，有时是不正确的，有时概念对单个域特别。例如，“工程工作表”只能由工程师使用，因此可能是其特定站点的对数。我不知道这很有说服力 - 但这是一个原因。

我执行的经验法则是，如果只使用一次东西，则可以拥有本地列表内容类型/字段。