早期绑定类的使用

本文关键字：绑定 | 更新日期: 2023-09-27 18:17:10

如果有任何刺激，请原谅。

在使用了早绑定类一段时间后，我们的团队注意到一些让早绑定类毫无用处的缺点。

问题:

  • 慢，因为它必须连接到web并通过http获取，即使它与系统的其他部分运行在同一个进程中。
  • 在插件中附加CREATE消息时导致sql死锁。
  • 系统和类的任何微小变化都需要重新生成，并且事情会中断。

那么它们什么时候有用呢?微软关于这些东西的文档在哪里?除了如何生成它们的教程。

谢谢,Jon

早期绑定类的使用

我们在开发中主要使用早期绑定类型。如果您开发业务逻辑(类型安全，…)，它们是有意义的。

但是，仍有使用晚界方法的空间。当我们必须保持通用性并且无法预测目标系统的样子时，我们使用的是后期绑定开发。或者如果你开发了一些可重用的组件，可以用多种方式配置(比如一个数字生成器)。

  • 慢，因为它必须连接到一个ws，并通过http，即使

在这一点上，早界规划和晚界规划没有区别。用.Update()更新晚绑定实体和在数据上下文中调用SaveChanges()的区别在哪里?当你在插件中使用早期绑定类时，不需要显式调用webservice。

  • 在插件中附加CREATE消息时导致sql死锁。

不是由早期绑定类型引起的。这种行为还有其他原因。

  • 系统和类的任何微小变化都需要重新生成，并且事情会中断。
我也不能同意这一点。类 的区别在哪里?
Account.Foo = "some data here";

或使用实体

Entity["new_foo"] = "some data here";

如果你在new_foo有变化，你必须处理早期和晚期绑定类。但是，如上所述，如果您不了解使用早期绑定类的目标环境，如果生成的属性引用的字段不可用，则可能导致问题。

早界有它的位置。我们在我们的web服务中使用它。它使开发迭代更加快速(例如，所有内容都是强类型的，因此围绕神奇字符串的调试更少。)

你提到的

:

•系统和类的任何微小变化都需要重新生成，并且事情会中断。

这实际上是Early bound的一个用例。在后期绑定中，您更有可能遇到只在运行时而不是在编译时才会注意到的破坏性更改。在编译时修复可以节省你的精力。

您还提到:

•在插件中附加CREATE消息时会导致sql死锁。

在我所见过的所有插件示例中，延迟绑定是事实上的标准。在我看来，您不会想要创建那么多繁琐的东西(特别是如果您生成所有实体)，以便在轻量级模块(如插件)中随身携带。从调试的角度来看，Execute方法中需要涉及的地理位置应该少得多。这减轻了前面提到的早期绑定的主要原因。

因此，如果您在系统外调用实体(例如在ESB中，或其他类似的业务实体)，则应该采用早期绑定。

这完全是基于我过去几个月在dynamics - cm -2011中开发的经验。您的里程可能会有所不同。

相关文章：