plugins - 早期绑定的（缺点）优点是什么？

Question

我正在研究 CRM 中早期和晚期绑定的优缺点。我对这个主题有一个好主意，但有些地方我不清楚。

有人说早买最快，有人说晚买。有什么显着差异吗？
如何处理自定义实体的早期绑定？
如何处理具有自定义字段的默认实体的早期绑定？

有很多链接，但最有用的是我的鼠标。还有其他指针吗？

亲都
 亲早
 临晚

score 28 · Accepted Answer

有人说早出价最快，其他人说晚出价。有什么显着差异吗？

一种。由于早期绑定只是后期绑定实体类的包装器，并且包含其中的所有功能，因此它的运行时不会比后期绑定更快。但是，这种差异非常小，我在 What's Fastest 类型的问题中与 Eric Lippert不同。一个不可忽略的速度差异是开发速度。早期绑定对于开发来说要快得多，而且更不容易出错恕我直言。
如何处理自定义实体的早期绑定？

一种。CrmSrvcUtil为自定义实体生成早期绑定的类，就像默认的一样（我创建了这个工具来使生成类更加容易。更新：它已经转移到GitHub 更新 2现在在 XrmToolBox 插件商店中，搜索为"Early Bound Generator"）。每次对 CRM 实体进行更改时，都需要更新实体类型定义（仅当您想要使用新的属性或实体，或者您已删除当前使用的属性或实体时。您可以使用过时的早期绑定实体类，只要您不设置任何实际不存在的属性的值，这与后期绑定的确切要求相同）
如何处理具有自定义字段的默认实体的早期绑定？

一种。请参阅问题 2 的答案。

使用早期绑定实体时的小问题之一是需要在您的IOrganizationService. 这对于 .js 来说很容易OrganizationServiceProxy，但对于插件，尤其是自定义工作流活动，可能需要更多步骤。

编辑 1 - 我的测试

下面是我的代码，针对一个相当不活跃的本地开发环境进行测试。随意为自己测试

using (var service = TestBase.GetOrganizationServiceProxy())
{
    var earlyWatch = new Stopwatch();
    var lateWatch = new Stopwatch();

    for (int i = 0; i < 100; i++)
    {
        earlyWatch.Start();
        var e = new Contact() { FirstName = "Early", LastName = "BoundTest"
        e.Id = service.Create(e);
        earlyWatch.Stop();

        lateWatch.Start();
        var l = new Entity();
        l.LogicalName = "contact";
        l["firstname"] = "Late";
        l["lastname"] = "BoundTest";
        l.Id = service.Create(l);
        lateWatch.Stop();

        service.Delete(e);
        service.Delete(l);
    }

    var earlyTime = earlyWatch.ElapsedMilliseconds;
    var lateTime = lateWatch.ElapsedMilliseconds;
    var percent = earlyWatch.ElapsedTicks / (double)lateWatch.ElapsedTicks;

}

我的两个测试结果（请注意，运行两个测试在统计上并不显着，无法得出任何统计结论，但我认为它们赋予了它的权重，因为它并没有那么大的性能下降来证明一些开发收益是合理的）在哪里运行针对本地开发环境，几乎没有其他活动来破坏测试。

Number Creates  |   Early (MS)  |   Late (MS)   |   % diff (from ticks)
10              |   1242        |   1106        |   12.3%
100             |   8035        |   7960        |   .1%

现在让我们插入数字并查看差异。12% 看起来很多，但 12% 是什么？实际差异为 0.136 秒。假设您Contacts每分钟创建 10 个... .136 x 60 分钟/小时 x 24 小时/天 = 195.84 秒/天或每天大约 3 秒。假设您花了 3 个开发人员小时试图找出哪个更快。为了让程序能够节省那么多时间，需要 60 天的 24/7 10 联系人/分钟处理，以便更快的代码“回报”3 小时的决策。

所以规则是，总是选择比首先更快的方法更具可读性/可维护性的方法。如果性能不够快，那么看看其他可能性。但是 100 次中有 98 次，它确实不会以最终用户可以检测到的方式影响性能。

过早的优化是万恶之源——DonaldKnuth

score 17 · Accepted Answer

可能不是。如果您想确定，我建议您运行一些测试并分析结果。

然而，这些 MSDN 文章建议后期绑定它更快。

使用 Microsoft Dynamics CRM 进行开发的最佳实践

使用早绑定类型

当您的代码必须处理编写代码时未知的实体和属性时，请使用 Entity 类。此外，如果您的自定义代码与数千个实体记录一起使用，则使用 Entity 类会导致比早期绑定实体类型稍好一些的性能。但是，这种灵活性有一个缺点，因为您无法在编译时验证实体和属性名称。如果您的实体已在代码时定义并且轻微的性能下降是可以接受的，您应该使用可以通过使用 CrmSvcUtil 工具生成的早期绑定类型。有关详细信息，请参阅在代码中使用早期绑定实体类。

为 Microsoft Dynamics CRM 选择托管代码的开发风格