early bound classes usage

Question

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

Baseburner

Answer 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.

Passerby

thx for commenting. "That is not caused by early bound types. There are other reasons for this behavior." Do you have proof of this? We have tested pretty extensively and using early bound classes seems to create a seperate db transaction which deadlocks with the context of the plugins transaction, eventually a timeout will occour from sql. Using late bound only, no issues. – Baseburner

For the breaking changes issue your correct for the metadata part in your example, but say your only getting the entity not working with any properties, if the early bound doesnt match exactly it crashes. Late bound if you don't specify modified fields, it doesnt break. – Baseburner

@JonC Both SaveChanges and Update use the same technical way to execute the requested operations. There is the possibility of problems with db locking. However this is not caused by only using early bound types. You should experience the same behavior with plain webservice usage if you do the same. We use early bound types in Create without problems. Maybe you should ask a separate question on this. – Passerby

All your comments and suggestions make sense. Thanks for the discussions and helping out with this. I'll create some more specific questions to get to the bottom of it :) – Baseburner

Answer 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.

Parous

Thanks for your comments on this. Since our early bound DLL is already running and a change is made via the CRM system we wont get compile time errors, thing just don't work or throw errors. For the plugins we were using filtered early bound so we weren't using the full 5mb dll. I was hoping early bound would help for RAD and get rid of the hard-coded strings. Now it looks like we'll have to refactor after our current release :( – Baseburner

@fauxtrot Agree entirely, Ive personally found early bound useful for developing a custom import that has needed heavy logic for creating related entities in CRM that Inaport wouldnt necessarily cover, Though i do find latebound a bit more bullet proof with installations that can change ( eg if a user removes an attribute ) – Disrespectful

One other thing that hasn't been discussed is the OData interface. We have used this so far in our silverlight webparts when we need to retrieve more data and want to do this without using dynamic scriptobjects. This gives you strong typing and you can use IgnoreMissingProperties = true on the context instanciation, making it a bit more flexible. – Parous