MSCRM 的感受

这几天看了一下MS的CRM产品，感觉其中使用到的开发架构和开发技术都是非常不错，其中的很多想法非常的有创造性的想法，很多想法我以前从来没有听说过，像什么自定义实体、如何将这些实体与业务插件结合起来、如何与视图、工作流等集成起来。感觉想法非常先进。

但我发现其中只是定义了一个实体的一组标准的操作，目前我还没有看到添加实体的扩展自定义操作，只看到了标准的创建、更新、删除和选取等操作。这样的操作如果在实现基本的业务上可能能够满足要求，但如果需要开发一个有很多自定义业务操作的实体，我想这种操作能否满足要求。

同时其中的插件在这里我想非常的不错，相当于一个职责链和观查者模式的实现，当进行某一操作时，根据对实体和操作的插件进行调用可以触发更多的事件的执行，这相当于将整个业务逻辑代码的AOP实现，这一点非常值得学习。相当于整个实体的业务操作是配置出来的，我想可能在设计时是按以下方式来设计的：

    实现一个业务实体操作的基本插件，用于实现数据库操作和工作流的集成和其它的一些基本的功能。

    再针对于特定实体业务逻辑编写若干的插件，实现特定的业务。

    调用过程中根据注册插件的顺序先执行自定义插件，再调用基本插件完成整个操作。

    我想这一过程肯定是一个有点慢的过程，但如果能够通过相关的信息，将这一组操作通过Emit之类的技术实现为一个动态创建的类，再来调用这个类，我想就能够获取的灵活的业务它高效的运行效率。

同时我想MSCRM解决了开发中的很多个问题包括：业务实体的属性变化问题、业务逻辑它业务流程的变化问题、视图的相关问题。这些问题的变化我们通常都需要通过二次开发来解决，很可能需要修改整个项目来解决，但MSCRM在这里解决得很好，是应当学习和应用的。

但同时我想如果将这个架构和来开发大型的像ERP那样的项目是否可很，特别是增量的开发。先根据需要开发不同的应用程序，后根据不同企业的不同需要布署不同的应用，如：

CRM：客户关系管理

PM（Product Management)：产品管理

SM (Sale Management）：销售管理

如这三个产品是公司目前的产品，针对于三种不同的用户，

其中的CRM与PM、SM之中都包括有Product，但其中的CRM之中包括有最简单的Product而，PM之中包括有产品最详细的技术资料，那么，当同时为同一家公司部署这三个产品之时，对于这个Product怎么样解决呢，能否相互使用相同的Product呢。或许还需要进行更多的思考。