Microsoft Dynamics作为软件开发平台？

Question

我的组织正处于获得CRM 4.0作为通用软件开发平台的最后阶段。卖给我们的公司已经说服高层管理人员，CRM将解决我们所有的生产力问题，并使软件开发像点点击一样简单。(他们不读布鲁克斯。)

我已经接受了我无法阻止CRM强加于美国开发人员的事实，我一直在研究如何管理大规模CRM开发的复杂性。

到目前为止，我已经确定了需要解决的下列复杂问题：

与基本配置管理practices.

• Keeping完全不兼容

1. 数据库与外部LOB系统双向同步，对于项目的成功是非常困难和关键的。

在构建大规模的CRM应用程序时，我必须考虑到哪些其他复杂性？

CRM作为一个开发平台有哪些局限性？

编辑：这个topic提供了更多的洞察力。

Answer 1

我使用了MSCRM3.0，现在是4.0，以下是我的看法：

只要有可能，

1. 就会专注于标准最佳实践。不要对CRM正在做什么或想让您做什么感到过于困惑。
2. 不要害怕打破女士“支持”的东西，但要注意两个主要因素--您的公司会让您跳出框框来解决问题，并进行不受官方支持的自定义/集成吗？--您是否对.Net、SQL、javascript等工具感到满意，可以编写它们的代码并实现您所需要的？

有时候，当我在这里对js文件进行小改动或对js文件进行小小的数据库修改，给我所需要的东西时，我会尝试着以一种“支持”的方式做100次尝试。如果与其他LOB应用程序保持数据集成是至关重要的，那么

• 应该考虑像Scribe (http://www.scribesoft.com/)这样的第三方工具。这并不便宜，但在与其他LOB应用程序集成时，它基本上可以让你获得90%的好处。

• 作为一项一般规则，MS擅长联系管理--比如跟踪约会、邮件合并等。你能把它作为核心人力资源系统吗？金融系统-也许更难一些。离执行联系人管理的核心能力越远，您需要做的定制工作就越多。您需要做的定制工作越多，您就越应该考虑more是否是解决该问题的正确方法。

Answer 2

我知道您很可能已经开始部署Dynamics，但只需要几个简单的提示：

• 我将避免进行不受支持的更改，纯粹是因为很难最终跟踪这些更改。由于Dynamics允许开发人员制作C#插件和访问web服务，所以对于任何不受支持的更改通常都是不必要的。此外，如果你必须调用他们的支持，那么你就必须对MS隐藏更改的轮盘。我知道许多人会包括外部javascript文件(jquery等)和其他一些良性的更改，但是当不支持的编辑涉及到任何非可视的内容时，请尝试停止自己的思维。
• 研究了Microsoft这个短语，有几本关于这个主题的书是很棒的，http://www.thecrmbook.com/特别好，因为它附带了一些很好的定制代码，可以与您的客户关系管理一起使用。
• 源代码控制您的定制xml，并且不允许人们触摸数据库，也就是Google工具，并使用它来编写出客户关系管理自定义和javascript文件。比编写定制的powershell脚本做同样的工作更容易。

Answer 3

事务支持

如果您的应用程序需要底层平台的事务支持，则Dynamics不是正确的选择。原因是因为目前Dynamics服务不支持事务。

引用线程在这里：Does MSCRM web-service support database transactions?

因为您希望使用Dynamics作为平台，这意味着所有的业务逻辑都应该使用服务作为数据访问层。但是想象一下，如果没有事务支持，您将一系列web服务调用作为一个工作单元调用，而其中一个web服务调用失败。这意味着您可能会遇到数据完整性问题。

配置

通常，我创建一个名为Configuration的自定义实体，它将存储当前CRM应用程序所需的所有相关配置。创建它之后，可以使用Dynamics服务从配置自定义实体读取所有必要的配置