今天我们来看看API的变化。新系统中,去掉了一些经常使用的数据处理API,比如:SetStateRequest, SetBusinessUnitRequest, SetParentBusinessUnitRequest等。
如今我们做这类型的操作不须要单独的调用这类API了,我们能够直接构造我们期望的Entity对象。并将其推送到服务端。系统将会安装其内容做对应的处理。
俗话说,外行看热闹。内行看门道。
尽管不过简单的去掉了几个API,可是对于新系统的内部架构应该是发生了翻天覆地的重构。
对于我们开发人员来说。这种调整是绝对的好消息,由于我们能够再设计系统脚本或者是数据接口的时候。极大的降低与server的交互次数,也就是说,假设我们用这个新的改变去重构之前的接口程序。性能会得到极大的提升。
本文将不讨论全部涉及到修改的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