plugins - 早期绑定(bind)的(缺点是什么？

Question

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

有人说早买最快，有人说晚买。有什么显着差异吗？

如何处理自定义实体的早期绑定(bind)？

如何处理具有自定义字段的默认实体的早期绑定(bind)？

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

Pro both
Pro early
Pro late

Answer 1

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

一种。由于早期绑定(bind)只是后期绑定(bind)实体类的一个包装器，并且包含其中的所有功能，因此它的运行时不会比后期绑定(bind)更快。但是，这种差异非常小，我与 Eric Lippert in the What's Fastest type of questions 不同。 .一个不可忽略的速度差异是开发速度。早期绑定(bind)对于开发来说要快得多，而且更不容易出错恕我直言。

如何处理自定义实体的早期绑定(bind)？

一种。 CrmSrvcUtil generates the early bound classes对于自定义实体，与默认实体完全相同(我创建了 this tool 以使生成类更加容易。 更新 :它已移至 GitHub 更新 2 现在在 XrmToolBox 插件商店中，搜索 "Early Bound Generator" )。每次对 CRM 实体进行更改时，都需要更新实体类型定义(仅当您想要使用新的属性或实体，或者您已删除当前使用的属性或实体时。您可以使用过期的早期绑定(bind)实体类，只要您不设置任何实际不存在的属性的值，这与后期绑定(bind)的确切要求相同)

如何处理具有自定义字段的默认实体的早期绑定(bind)？

一种。见问题 2 的答案。

使用早期绑定(bind)实体时的小问题之一是需要在 IOrganizationService 中启用早期绑定(bind)代理类型。 .这对 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;

}

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

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

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

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

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