记D365开发的最佳实践
作者：互联网
前端JS
不同的需求应该划分模块，以便日后修改，也是为了职责分离，模块分离，日后如果想分离到单独的JS文件里面也是比较方便；
对于公共的查询函数，应该做缓存，优先使用sessionStorage。
多个查询可以并行的，就并行查询。
通常一个需求会同时在onload和onchange中同时调用，需要区分的不同点，不要在onload中调用setValue函数
在性能要求不是很极致的情况下，addOnChange写在代码里面管理起来更方便，而不是定义在from中
插件开发
应该多利用pre-Validation阶段，该阶段不会进入事务，也就是说业务规则校验的时间不会影响事务执行时长，当处在事务中的记录会被锁定，缩短事务时长可以让记录尽快的释放锁，减少系统阻塞时间。
对于非本实体的操作，利用异步的postUpdate，可以让插件效率更高。举个例子，case关闭之后更新客户的某个字段，在case状态更新之前，主要的处理逻辑放在PreCaseUpdate里面；当case状态更新之后，注册在PostCaseUpdate中并设置为后台执行的插件处理更新客户字段逻辑。这样做的好处是：1. 调用SDK更新case状态的操作效率更高，不会受更新客户的逻辑影响。2. 当系统开放接口更新case的时候，接口性能更高且可以复用插件逻辑；而不是因为插件性能问题，跳过插件，在接口中重写一遍更新客户的逻辑。
工作流开发
不要在工作流中写过多业务逻辑，尽量做成可配置的步骤，这样，在某个步骤失败时在客户端就知道，而不是在Trace中查找。
集成开发
集成必须有管控，需要知道系统跟哪些外部系统做了集成，接口清单需要明确，且可管理，比如说可以随时停用；而不是让外部系统直接调用SDK。
集成需使用https协议、访问外部系统配置跨域。
基础设施
消息队列，缓存，日志
架构
部署架构：
微服务
技术架构：
API gateway、高可用、前后端分离、主备库
标签：case,插件,调用,实践,更新,D365,最佳,接口,逻辑 来源： https://www.cnblogs.com/tcli/p/12635917.html