今天我们来看看API的变化，新系统中，去掉了一些常用的数据处理API，例如：SetStateRequest, SetBusinessUnitRequest, SetParentBusinessUnitRequest等。现在我们做这类型的操作不需要单独的调用这类API了，我们可以直接构造我们期望的Entity对象，并将其推送到服务端，系统将会安装其内容做相应的处理。
俗话说，外行看热闹，内行看门道。虽然只是简单的去掉了几个API，但是对于新系统的内部架构应该是发生了翻天覆地的重构。对于我们开发者来说，这样的调整是绝对的好消息，因为我们可以再设计系统脚本或者是数据接口的时候，极大的减少与服务器的交互次数，也就是说，如果我们用这个新的改变去重构之前的接口程序，性能会得到极大的提升。
本文将不讨论所有涉及到改动的API，而是简单介绍几个我们日常80%会使用的API：AssignRequest 和SetStateRequest。简单介绍它们在调整后应该怎么使用，为大家起到抛砖引玉的效果。
可以参考下面的代码片段，，这里我们对一条客户记录进行了2种操作：分派和设置属性。大家也可以发现，所有的这些操作都是在Entity Level实现的，并没有调用额外的Requests。

//set state Entity 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 owner if (testEntity != null) { testEntity["ownerid"] = new EntityReference("systemuser",userId); } //set state if (testEntity != null) { testEntity["statecode"] = new OptionSetValue(1); testEntity["statuscode"] = new OptionSetValue(2); } CrmSvc_Online.Update(testEntity);

当然，现在系统仅仅重构了为数不多的API，相信随着后续的跟新，系统将会更便利的开发体验给广大的开发人员。下面是已经支持Entity Level调用的API，当然其对于的API将会被废弃：D

AssignRequest –> Entity.OwerId

SetStateRequest –>Entity.StateCode

SetParentSystemUserRequest –>SystemUser.ParentSystemUserId

SetParentTeamRequest –>Team.BusinessUnitId

SetParentBusinessUnitRequest –>BusinessUnit

SetBusinessEquipmentRequest –>Equipment.BusinessUnitId

SetBusinessSystemUserRequest –>SystemUser.BusinessUnitId