假设在项目中存在一个呈现无序列表的表示组件（可能称为ListRenderer。）我们有几个选项可以向页面上任何给定的ListRenderer提供数据：
我通常会在项目中避免使用＃1，因为它会将Sublayouts绑定到模板，这会非常混乱。如果沿着这条路走下去，最终你将拥有支持项目中每个潜在子布局的字段。
所以我的解决方案倾向于选项＃2，它解决了这个问题。然而，它确实带有一系列问题。我在哪里为给定的ListRenderer使用这些不同的“列表”？为了最大化重用和共享，我通常在站点根目录附近创建一个包含所有这些类型的组件的组件目录，如果我预测将共享列表。对于内容作者来说，这似乎更难以找到并且更难以使用，他们突然不知道他们的ListRenderer的来源在哪里，除非他们知道如何破解演示文稿的详细信息（这对我的普通用户来说稍微提前）。
如果我觉得列表不会被共享，并且非常特定于页面，我会将它们直接放在相关项目下方。然而，这倾向于混淆内容树，并且任何动态生成的导航子布局然后必须在其生成到其的链接之前检查该项是否是实际页面。我在Sitecore中工作的越多，我使用这种方法的次数就越少，但对内容作者来说似乎更容易。使用这种方法时，可以更轻松地访问信息。
是否有任何行业认可的方式来解决这个问题？它一直发生在项目中，在我的脑海中，我努力在这些情况下平衡技术和内容作者关注点。
答案 0 :(得分：7)
好问题。我已经使用了你提到的所有技术，具体取决于项目的受众和细节。问题在于，就像Sitecore一样，它们都是实现相同目标的有效方法，您将很难找到一个适用于所有情况的答案。
我几乎总是使用＃2，但是某些内容作者可能需要重新训练，并确保对内容作者选择作为目标的内容添加限制。我（在同一个项目中）构建了根目录（在共享内容文件夹中）和相关项目下的项目，具体取决于我认为会提供最佳背景。
此外，如果项目下方和列表项目下面还存在其他子页面，那么我会将列表项目放在一个单独的文件夹中（带有一个共同的“列表项”图标“）并重新排序为第一个分离和清晰的项目。
如果您想使用任何类型的个性化和DMS，那么您将需要能够切换数据源，因此您不应该硬编码位置。
您可能（如果您还没有）想要考虑使用：
Convert Data Source Paths to IDs Using the Sitecore ASP.NET CMS
- 如果您需要在以后重新构建内容，则非常有用
Queryable Datasource Locations
- 当您需要进行克隆时，对于多站点情况很有用，或者当列表直接位于项目下方时设置为标准值中的默认数据源值，但是您可以灵活地进行更改。
我更喜欢亲自使用可交换的数据源，我发现xpath语法更合乎逻辑。
答案 1 :(得分：4)
正如马克评论的那样，没有真正的行业标准。
我觉得这是需要改进的事情。 特别是在使用DataSource选项时，编辑器的透明度会降低，随着网站规模的增大，复杂性也会增加。
我只能告诉你我是怎么做到的，这很可能与你的做法非常相似。
1）对于新闻，事件和常见问题项目等概述页面，我将把项目放在概览项目下面，并使用NewsMover共享源模块自动创建层次结构。
2）我将创建一个全局站点，其中包含跨站点或页面共享的项目。组件的DataSource项目将放在此处。
3）对于标准值上存在的组件，我将向模板添加一个列表字段（例如，当您在内容页面上显示相关项目时）
大多数情况下，这是一个合乎逻辑的选择，有时只是品味问题。
我想补充一点，我已经编写了一个blog post，关于如何为标准值设置的组件自动创建数据源项。如果您使用它们，这可能对您有所帮助。
修改 “我通常会在我的项目中避免使用＃1，因为它会将Sublayouts绑定到模板，这会非常混乱。如果沿着这条路走下去，最终你将拥有支持项目中每个潜在子布局的字段。”
今天我blogged关于在内容编辑器中隐藏字段和部分的方法，如果在需要这些字段的项目上没有设置子布局，这有助于防止有大量未使用的混乱您商品上的字段。