今天我们来看看API的变化，新系统中，，去掉了一些常用的数据处理API，例如：SetStateRequest, SetBusinessUnitRequest, SetParentBusinessUnitRequest等。现在我们做这类型的操作不需要单独的调用这类API了，我们可以直接构造我们期望的Entity对象，并将其推送到服务端，系统将会安装其内容做相应的处理。 俗话说，外行看热闹，内行看门道。虽然只是简单的去掉了几个API，但是对于新系统的内部架构应该是发生了翻天覆地的重构。对于我们开发者来说，这样的调整是绝对的好消息，因为我们可以再设计系统脚本或者是数据接口的时候，极大的减少与服务器的交互次数，也就是说，如果我们用这个新的改变去重构之前的接口程序，性能会得到极大的提升。 本文将不讨论所有涉及到改动的API，而是简单介绍几个我们日常80%会使用的API：AssignRequest 和SetStateRequest。简单介绍它们在调整后应该怎么使用，为大家起到抛砖引玉的效果。 可以参考下面的代码片段，这里我们对一条客户记录进行了2种操作：分派和设置属性。大家也可以发现，所有的这些操作都是在Entity Level实现的，并没有调用额外的Requests。
//set stateEntity testEntity = null;Guid userId = Guid.Parse(“{7651C7AF-8B18-E511-80E0-3863BB2E8C90}”);Guid userId2 = Guid.Parse(“{461C2001-C724-4DFE-BA6E-ED2D274784D2}”);Guid teamId=Guid.Parse(“{BC2D90A5-F221-E511-80E1-3863BB2E7CD8}”);Guid parentBUId=Guid.Parse(“{4FE4929F-F221-E511-80E1-3863BB2E7CD8}”);Guid BUId=Guid.Parse(“{A4448DF6-F221-E511-80E1-3863BB2E7CD8}”);QueryExpression query4Acc = new QueryExpression(“account”);query4Acc.ColumnSet = new ColumnSet(true);EntityCollection accounts = CrmSvc_Online.RetrieveMultiple(query4Acc);if (accounts.Entities.Count > 0){testEntity = accounts.Entities[0];}//set ownerif (testEntity != null){testEntity[“ownerid”] = new EntityReference(“systemuser”,userId);}//set stateif (testEntity != null){testEntity[“statecode”] = new OptionSetValue(1);testEntity[“statuscode”] = new OptionSetValue(2);}CrmSvc_Online.Update(testEntity);
当然，现在系统仅仅重构了为数不多的API，相信随着后续的跟新，系统将会更便利的开发体验给广大的开发人员。下面是已经支持Entity Level调用的API，当然其对于的API将会被废弃：D
接受失败更是一种智者的宣言和呐喊
