问题
Please excuse any irritation that may come through.
So after using the early bound classes for a while now our team has noticed some cons that make early bound classes pretty useless.
Issues:
- Slow, since it has to connect to a ws and get over http, even thought it's running in the same process as the rest of the system.
- Causes sql deadlocks when attaching to CREATE message in a plugin.
- Any slight change to the system and the classes need to be regenerated and things break.
So when are they useful? Where's MS documentation on this stuff? Besides how to generate them tutorials.
Thanks, Jon
回答1:
We mostly use early bound types for our development. They make sense if you develop business logic (type safety, ...).
However, there is still room for the late bound approach. We are using late bound development, when we have to stay generic and can't predict how the target system looks like. Or if you develop some reusable component which could be configured in multiple ways (like a number generator).
- Slow, since it has to connect to a ws and get over http, even though it's running in the same process as the rest of the system.
There is no difference between early and late bound programming in this point. Where is the difference of updating a latebound entity with .Update() and calling SaveChanges() on your data context? You don't have to call the webservice explicitly when you are using early bound classes in plugins.
- Causes sql deadlocks when attaching to CREATE message in a plugin.
That is not caused by early bound types. There are other reasons for this behavior.
- Any slight change to the system and the classes need to be regenerated and things break.
I also can't agree on this point. Where is the difference between having a class
Account.Foo = "some data here";
or using Entity
Entity["new_foo"] = "some data here";
If you have changes at new_foo you have to handle that with early and late bound classes. However, as mentioned above, if you don't know the target environment using early bound classes could lead to issues if the fields referenced by the generated properties are not available.
回答2:
Early bound has its place. We use it in our webservice teirs. It makes for a more rapid development iteration (e.g. everything is strongly typed, and therefore there is less debugging centered around magical strings.)
You mentioned:
•Any slight change to the system and the classes need to be regenerated and thing break.
This is actually a use case for Early bound. In late bound you are more likly to be stuck with breaking changes that you will only notice at runtime rather than at compile time. Fixing at compile time saves you energy.
You also mentioned:
•Causes sql deadlocks when attaching to CREATE message in a plugin.
In all the plugin examples I've seen, late bound is the defacto standard. In my opinion you wouldn't want to create that much cruft (especially if you are generating all entities) to lug around in a lightweight module such as a plugin. From a debugging standpoint, there should be a lot less geography to cover from within the Execute method. This mitigates the primary reason for early bound, as mentioned previously.
So, if you are calling entities off system (such as in a ESB, or some other such business teir) early bound is the way to go.
This is based solely on my experience in developing in dynamcis-crm-2011 for the past few months. Your milage may vary.
来源：https://stackoverflow.com/questions/8421168/early-bound-classes-usage