Dataverse : Early bound vs Late bound programming

1

min read

A- A+

read

In this post I'd like to highlight some important points when deciding between Dataverse : Early bound vs Late bound programming.

Tooling

Both programming models provide excellent tooling support by XRM toolbox.

Late-bound
Dataverse : Early bound vs Late bound programming
Early-bound
earlybound_tool

Generated classes

Make sure to only generate code for the entities, which are used in the solution.

Late-bound
Generated classes are small, simple and easy to understand. Basically, it's just a collection of static string fields.
Dataverse : Early bound vs Late bound programming

Early-bound
Here, you get the benefit of typed classes and compile-time type checking. Generated class files can grow quite fast. For each field two partial methods named OnPropertyChanging and OnPropertyChanged are generated, which can be extended with custom business logic.
Dataverse : Early bound vs Late bound programming

LINQ

Both programming models are supported by the LINQ provider. An OrganizationServiceContext can optionally be generated using Early Bound Generator tool. This allows querying data using LINQ syntax. However, it also requires you to understand how objects are handled by the context.
See:

Query objects

For both programming models: As a best practice avoid selecting all fields while retrieving data.

NULL values in queries

Late-bound
If an attribute is not included in the Entity.Attributes collection, it is either NULL or it was not selected in the query.

Early-bound
If a value is NULL in the generated Entity class property, it is either NULL or it was not selected in the query.

NULL values in plugin target entity

Late-bound
If an attribute is not included in the Entity.Attributes collection, it wasn't updated by the user. If the user removed the value from the attribute, it would appear as NULL value in the Entity.Attribute collection.

Early-bound
If a value is NULL in the generated Entity class property, the user either removed the value from the property or it wasn't updated at all. It's not clear. Thus, use the late-bound approach to get the list of updated properties.

Update objects

For both programming models
As a best practice don't update an object using the retrieved instance. Better instantiate a new object and set the primary key value to match the object you want to update. Only set the attribute values you are changing.

Avoid updates like this:

Dataverse : Early bound vs Late bound programming — Only "Account Number" field should be updated

Conclusion

Both programming models work great for certain scenarios. Although it's possible to mix both approaches, I won't recommend it. Agree on one approach and try to maintain a consistent code style in your project. Especially for plugin development, I prefer the late-bound approach because of its simplicity and clear programming model.
Additional guidance can be found on MS Doc https://docs.microsoft.com/en-us/powerapps/developer/data-platform/org-service/early-bound-programming