今天我们来看看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
版权声明:本文为博主原创文章,未经博主允许不得转载。
时间: 2024-10-08 11:45:38