When Not to Use Early Binding in MS Dynamics

June 10, 2019

What is an early binding in MS Dynamics

When creating a plugin for MS Dynamics you usually need to connect to your CRM instance like:

...
CrmServiceClient crmServiceClient = new CrmServiceClient(connectionString);
IOrganizationService service = new crmServiceClient.OrganizationServiceProxy;

Once you have your service connected, you have 2 options to interact with the crm entities. One is called Early Binding, another Late Binding. To use early binding, some setup is required before you can start. You have to generate the classes, which will make your life easier in some aspects. As the time goes by, we like to invent things to make life more convenient, this is also the case for the MS Dynamics ecosystem. There is a code generation tool (console app) for extracting the current state of the classes from your Dynamics instance. This is called: CRMSvcUtil. This is very convenient, but there is an even more convenient way to do this (and has been for some tme), which can be found in the XrmToolBox. Its name is of course an Early Bound Generator

After you've read through the documentation and generated those files you needed (some, or all entities). You'll now have Early Binding at your disposal. You'll see XrmContext.cs, packed with a bunch of entities and option sets you have generated. They can be easily used like this:

Account account = new Account() { Name = "someName", EMailAddress1 = "someEmail@someDomain.com" };
service.Create(account);

What is a late binding

When using late bound entities, the only thing you need is service and Entity class, which is part of SDK out of the box. Late binding looks like this:

Entity account = new Entity();
account["name"] = "someName";
account["emailaddress1"] = "someEmail@someDomain.com";
service.Create(account);

Not that bad, is it? But what if I have like 20 attributes, do I have to have same amount of lines? ...you ask. No, you can use:

AttributeCollection attributes = new AttributeCollection();
foreach (var attribute in someAttributeList)
{
    attributes.Add(attribute);
}

The AttributeCollection accepts any string-object pairs. But still, once all the work is done, the early bound example looks easier and cleaner to use. Why should you not use it?

When not to use early binding

When you face more complex/abstract problem, and you need to do similar field on multiple entities based on configuration you have passed in.

For example, if you want to do same operation on each child every child record, regardless of what type it is, you will have a hard time using early binding for this. Whereas using late binding will be flexible enough, because everything is an Entity and has the same attribute, you don't care that other attributes are totally different.
When the team cannot agree on which entities/option sets to generate and which not.
When you prototype something, it probably isn't worth it to generate early bound, as well as you will sacrifice some flexibility.

Otherwise, always use early bound entities. They are comfortable to write, and ensure type safety.