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
Early-bound
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.
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.
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:
- https://docs.microsoft.com/en-us/powerapps/developer/data-platform/org-service/organizationservicecontext
- https://community.dynamics.com/crm/b/develop1/posts/do-you-understand-mergeoptions
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:
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
Add new comment