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:
So when are they useful? Where's MS documentation on this stuff? Besides how to generate them tutorials.
Thanks, Jon
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.