动态CRM -可能性和局限性

Question

我有一些可能是模棱两可的问题，我不知道我是否能得到正确的答案，但我想我会把它说出来，因为我不知道在哪里可以得到答案。

作为一个部门，过去两年一直在实施各种现代开发实践，敏捷、Scrum、TDD、持续集成、MVC。

我的公司现在将转向，(目前我们使用第三方产品)。他们想使用Dynamics，但也为了定制定制开发，通过阅读和背景学习，我可以体会到Microsoft Dynamic是一款优秀的产品，它有它的地位，并且为许多企业解决了问题。我对微软动力的知识来自以下视频。http://channel9.msdn.com/Series/DynamicsCRM2011

我们的实现很可能是高度定制的业务，我们还将在Dynamics中构建大量的定制应用程序。我的公司是微软公司，所以我们已经使用了.NET，Server等。

我的问题：

• 微软动力是否允许现代开发实践，如TDD，持续集成，MVC？
• 如果CRM部分是高度定制的，我们会失去使用Dynamics的好处吗？
• 它在市场上作为一种产品的声誉如何？
• 与定制MVC应用程序相比，在Dynamics中开发具有大量业务规则的定制定制应用程序是更快还是更慢？
• 已知的限制或缺点是什么？
• 如果有的话，还有其他好的选择吗？

我意识到没有答案，只有意见，如果有人使用或有一个观点，或可以指出一些好的联系，平衡意见和事实，这将是非常感谢的。

谢谢。

Answer 1

Microsoft是一个非常棒的产品，它提供了一个非常好的应用程序框架。就像任何框架一样，它并不是最适合所有情况的。一般说来，CRM非常适合需要关系和/或工作流的结构化数据解决方案。

我们使用CRM后端构建MVC应用程序，它更像是一个SQL数据库；然而，这些应用程序通常是为访问门户的非CRM用户提供的。通常，对您的客户关系管理用户来说，您是通过JavaScript、插件(例如C#)和iFrames (指向您想要的任何东西)来定制产品。

当涉及到测试驱动开发(TDD)或持续集成(CI)时，没有标准的CRM工具来帮助您。我们已经构建了一些工具来自动化/协助我们的开发，使用SDK很容易做到这一点。单元测试您的插件应该很好地符合您正在做的任何事情。但是，您正在测试UI中的MVC应用程序，目前还应该继续使用，所以您在开发/qa过程中投入了多少精力是任何新框架都要考虑的问题。

如果CRM部分是高度定制的，我们会失去使用Dynamics的好处吗？

这取决于你想做什么。CRM是建立在关系上的。因此，如果您想使用一堆非相关实体自定义解决方案，而不使用工作流、安全性等，那么我想说CRM不适合您。

与定制MVC应用程序相比，在Dynamics中开发具有大量业务规则的定制定制应用程序是更快还是更慢？

通常，在CRM接口中开发某些东西要比开发非CRM应用程序要快得多。问题的一部分将是提高您的开发人员。

如果出现了MVC方法更适用的情况，那么您可以开发一个MVC应用程序，它可以与CRM (或SQL)对话，并与左手导航集成在CRM中。

已知的限制或缺点是什么？

Sharepoint更适合用于非结构化数据。所以，我想说这是CRM的一个弱点。SQL数据库中有很多支持CRM的移动部件，所以如果您有一个SQL应用程序对多个数据库进行集群，那么我不会增加开销。唯一的缺点是坡度上升。

和任何工具一样，知道什么时候使用它与不使用它是关键。CRM并不是万能的解决方案，但我已经看到它对众多行业的客户产生了神奇的效果。

完全公开，我是一个微软合作伙伴的开发人员。我强烈建议您有一个合作伙伴，为您提供培训，入门模板等，以增加您的开发时间。