Partager via

To be Strongly typed or not to be....

  • Article

When we were designing the Microsoft Dynamics CRM V3.0 web services, we had a lot of discussions around how strongly typed our Object Model should be. Some developers including myself (although I am a “Program Manager” at Microsoft) would strongly prefer strongly typed classes because they simply provide a better development experience (e.g. VS.NET IntelliSense, design/compile time error checking). But CRM is really a dynamic system which means it could have a lot of customization already done to it. In that case, if you are building applications that should work with any CRM implementation, at your design time you didn’t know about the types that may exist on your target CRM implementation. For that reason, we invented the notion of DynamicEntity. DynamicEntity includes a collection of strongly typed properties but unlike a typical Strongly typed Business Entity like account, does not have those properties exposed on the DynamicEntity class. Here are some examples:

 

If I want to create an account using Microsoft Dynamics CRM V3.0 web services object model , I have two options:

 

 

CrmService myService = new CrmService();

myService.Url = CrmServicesURL + "CrmService.asmx";

myService.Credentials = System.Net.CredentialCache.DefaultCredentials;

 

//-------------------------------------

//Use the strongly typed class: account

//--------------------------------------------

account myAccount = new account();

myAccount.name = "X Company";

myAccount.telephone1 = "206-1133-578";

try

{

      Guid myNewAccountId = myService.Create(myAccount);

}

catch (SoapException e)

{

         //Show the error message

}

 

 

//-----------------------------------------------------------------------------------

//Use DynamicEntity class that has strongly typed properties in a collection

//-----------------------------------------------------------------------------------

DynamicEntity myAccount = new DynamicEntity();

myAccount.Name = EntityName.account.ToString();

          

StringProperty name = new StringProperty();

name.Name = "name";

name.Value = "X Company";

StringProperty telephone1 = new StringProperty();

telephone1.Name = "telephone1";

telephone1.Value = "206-1133-578";

myAccount.Properties = new Property[] {name, telephone1 };

try

{

  Guid myNewAccountId = myService.Create(myAccount);

}

catch (SoapException e)

{

         //Show the error message

}

The other cool feature in Microsoft Dynamics CRM V3.0 is the ability to query CRM metadata using the all new metadata web service(metadataService.asmx). All the metadata (e.g. business entity list, their attributes, their relationships, etc) are accessible using this web service. Put two and two together (metadata web service and Dynamic Entities) you can now easily discover customization at runtime and work with custom entities without requiring to have known about them at the design time......

Comments

  • Anonymous
    March 10, 2006
    I just saw that Arash Ghanaie-Sichanie (the Microsoft CRM Program Manager responsible for the...
  • Anonymous
    June 13, 2008
    Mr Blue Sky... I just saw that Arash Ghanaie-Sichanie (the Microsoft CRM Program Manager responsible