所以试图用KnockoutJS 3.2弄脏我的手。我已经阅读了文档，并且在当前项目中成功实现了组件。我没有使用AMD，所以我只是使用脚本元素来保存视图。
我的问题是：如果我没有使用异步加载功能，使用组件而不是模板是否有任何实际的区别？
答案 0 :(得分：17)
如另一个答案中所述，模板只是一段HTML，可以绑定到viewmodel或viewmodel部分。并且组件由模板及其对应的视图模型组成。此外，除了observable之外，这个视图模型还可以包含一些简单的业务逻辑和与服务器通信的功能。
另一个重要的区别是耦合。一个模板，它绑定到主视图模型，并绑定到主视图模型的可观察对象，因此它与视图模型高度耦合：视图模型中的更改将破坏模板，反之亦然。因此，如果您在多个地方重复使用模板，并且更改了模板，则必须更正相应的视图模型。
组件绑定到自己的viewmodel。如果有从其提供的参数，它仅耦合到主视图模型。这意味着您可以轻松更改组件模板以及组件视图模型，如果没有参数，或者您没有更改它们，则不会有任何内容被破坏。
因此，使用组件有助于解耦和模块化。
最后一部分是一把双刃剑：如果主视图模型与模板或组件之间存在高度交互，则使用模板会更容易，因为所有逻辑和属性都保存在主视图模型和交互很容易实现。如果您使用了组件，则需要提供复杂的参数，甚至可以制作一些允许组件向主视图模型公开功能的内容。
让应用程序的某些部分需要不同的行为和可视化来解决相同类型的任务并不奇怪。例如，让我们想象您必须在您的应用程序中实施支付系统：如果您接受PayPal和信用卡支付，则您有两种不同的可视化和功能。如果您使用了模板，则需要在主视图模型中具有每个支付系统的特定实现。如果您使用了组件，他们将共享一个公共接口（参数），但每个组件都有自己的实现。如果明天您必须包含一个新的支付系统，那么使用通用界面实现新组件将很容易。
注意：请注意最后一段
在模板的情况下，绑定不是在模板级别完成的，而是在模板级别内部完成的。即模板中的每个元素都必须绑定到主视图模型的可观察对象。对于组件，绑定更简单：最多需要组件名称和参数（如果存在）。
如果您注册该组件，则可以使用自定义标签。这使得视图更易于阅读和理解：不是在绑定中指定组件名称，而是使用带有组件名称的标记，并将参数作为属性传递。
如果您使用模板，则必须自己动态加载模板，并且由于这是一项异步任务，因此只有在模板已经可用时才需要使用该模板。在大多数情况下，您可以使用内联模板。如果它们必须在几个地方重复使用，那就不好了。
如果您已经使用了某些AMD实现，例如require.js，并且您了解此技术的好处，那么您将很高兴知道您可以轻松地使用AMD来加载组件模板和视图模型。其中一个优点是，当您需要使用模板或组件时，您不必担心它们可用。
无论您是进行手动还是自动化测试，都可以更轻松地逐个测试一堆独立组件，以测试带有或不带模板的复杂视图模型。
到目前为止，我已经公开了有关模板和组件的事实，并且我试图不显示我的个人偏好。但是，在最后一节中，我必须说在大多数情况下我更喜欢使用组件来实现它们的优势：
最后一段与大型应用程序有关。如果您正在处理小型应用程序或仅仅是对其他技术（如ASP.NET MVC）呈现的界面的增强，那么您可能无法获得使用组件的任何优势。所以，你不需要它们。
还有其他情况，它不值得使用组件。例如，如果必须显示具有不同属性的项目列表（JavaScript数组），这些项目必须以不同的方式显示，则更容易使用模板。请注意，在这种情况下的选择是因为每个实例都没有具有许多功能的复杂视图模型，而是一组简单的属性。在这种特殊情况下，它不仅不值得，而且使用组件也会适得其反。
您可以将此最后一个示例理解为多态。但是，在这种情况下它几乎＆＃34;视觉＆＃34;多态性。即每种项目必须以不同的方式显示，但不需要在每个组件中实现任何特殊逻辑。
然而，即使在这种情况下，如果模板足够复杂，或者必须在许多不同的地方使用，那么使用包含模板的简单组件也会好得多以及接收整个项目的参数。因此，即使在这种情况下，使用组件也不是一个坏主意。
如果你现在读到这里，谢谢你，我希望你有一些标准来帮助你选择最佳选择。
答案 1 :(得分：4)
他们并没有完全不同。组件由模板（html）和数据/逻辑（视图模型，即JavaScript）组成。当您有模块化视图时，您想要附加视图模型，您可以使用组件。这是一个更多地讨论组件的链接：http://www.knockmeout.net/2014/06/knockout-3-2-preview-components.html