When working with Dataverse (formerly Common Data Service, CDS) in Dynamics 365, there are two primary ways to interact with data programmatically using C#:
- Early Bound (Strongly Typed)
- Late Bound (Loosely Typed)
Each approach has its advantages and trade-offs, depending on the project’s requirements.
Early Bound (Strongly Typed)
Characteristics:
・Compile-time binding: The data structure is determined at compile time.
・Uses C# classes that represent entities and their attributes.
・Requires CrmSvcUtil.exe (or Power Platform Tools for Visual Studio) to generate entity classes.
・Provides IntelliSense and type checking, making code easier to read and write.
・Safer to use since typos are caught during compilation.
・Needs to regenerate entity classes whenever there are schema changes in Dataverse.
Example of Early Bound:
using (var service = new OrganizationService(context))
{
var contact = new Contact
{
FirstName = "John",
LastName = "Doe",
EmailAddress1 = "john.doe@example.com"
};
service.Create(contact);
}
・Contact
is a strongly typed C# class generated from Dataverse.
・The attributes (e.g., FirstName
, LastName
, EmailAddress1
) are pre-defined and validated at compile time.
Late Bound (Loosely Typed)
Characteristics:
・Runtime binding: The data structure is determined at runtime.
・Uses generic Entity
class, instead of pre-generated C# classes.
・No need to generate entity classes.
・More flexible and suitable for handling unknown or frequently changing data models.
・Lacks IntelliSense, making development more error-prone.
・Prone to typos, as attribute names are specified as strings.
Example of Late Bound:
using (var service = new OrganizationService(context))
{
Entity contact = new Entity("contact");
contact["firstname"] = "John";
contact["lastname"] = "Doe";
contact["emailaddress1"] = "john.doe@example.com";
service.Create(contact);
}
・The entity is created dynamically using the Entity
class.
・Attributes are defined as string keys (e.g., "firstname"
, "lastname"
, "emailaddress1"
).
・If there is a typo in an attribute name, there won’t be a compile-time error, but it will fail at runtime.
When to Use Each Approach?
Approach | Advantages | Disadvantages | Best Use Cases |
---|
Early Bound | ✔ IntelliSense support ✔ Type safety (compile-time validation) ✔ Easier to maintain in large projects | ✖ Requires regenerating entity classes after schema changes ✖ More setup required | Long-term projects Projects with stable data models When working with large, complex entity structures |
Late Bound | ✔ No need to regenerate classes ✔ More flexible for dynamic attributes | ✖ No IntelliSense ✖ Prone to runtime errors (typos) ✖ Harder to debug and maintain | Quick development Prototyping Projects where the schema changes frequently |
Besides Early Bound and Late Bound, you can also use:
- LINQ Queries (only with Early Bound).
- FetchXML (XML-based querying).
- Web API (for integration with external services).
Conclusion
・Use Early Bound when you need strong typing, IntelliSense, and maintainability.
・Use Late Bound when you need flexibility and are working with dynamic or frequently changing schemas.
・Each method has trade-offs, so choose based on your project requirements and development workflow.
コメント