我最近发现 salesforce.com 不仅仅是一个在线 CRM，因为我遇到了 Morrison 的案例研究，在该案例研究中他们开发了一个工作管理应用程序。我一直在尝试以在平台上重新创建我们自己的作品管理系统。
我的背景是 Microsoft 和 .Net，显而易见的第一选择是 asp.net。但是，实际上只有我自己具有 .net 经验，而我的经理具有更传统的 Synergy 编程背景，而且我是自学成才的，并且正在考虑评估其他 RAD 选项（例如 Ironspeed）。
该业务的性质主要是 2-5 个并发建设类型合同，每个合同运行 3-5 年，每个合同需要 15-50 个系统用户。传统上，我们对所有内容都使用了基于角色的 Works Mangement 系统，并针对每份合同进行了调整。Salesforce 许可模式表面上适合这种灵活性，但我担心开发灵活性/学习曲线以及围绕锁定的所有问题。对于不是销售人员自己的材料/博客的网络平台似乎没有太多中立的清醒分析
与更“传统”的 .Net 路线相比，有没有人在 Salesforce 上开发应用程序的经验？
除了最简单的应用程序之外，Salesforce 是一种相当痛苦的开发体验。Salesforce 对想要开发的内容有一个非常具体的想法，如果您的应用程序不在这些范围内，请避开！
调控器的限制真的很可怜：16 级递归，1 兆堆，一次查询返回不超过 200 个对象，一次调用不超过 20 个查询。一次调用中有 10 个 Web 标注，单个列表中有 1000 个项目，然后它们继续。最终的结果是，你想出的任何绕过一个限制的聪明都会与另一个限制发生冲突。
一旦你达到一定的规模，你所有的时间都将花在围绕这些限制进行编码上。Apex 语言并不真正支持任何有意义的继承。即使看似简单的任务最终也会遇到新的且明显任意的限制，例如，Apex 中的所有对象都继承自SObject; 但是，不允许实例化泛型集合SObject，因此几乎不可能构建有用的实用程序库。复杂（甚至相当简单）的数据库连接是不可能的。
对 Salesforce 的工具和支持也非常薄弱。它们是不可信的，难以用于实际的开发过程。部署是一场噩梦，因为这些工具很难解决复杂的依赖问题，而且在正常开发过程中创建的众多实体根本无法以编程方式部署。其他小功能也很令人愉快，例如语言不区分大小写，但 IDE 区分大小写。没有重构工具可言，因此您会感受到静态类型语言的所有痛苦，而没有任何所谓的好处。而且保存/编译时间很长——我看到频率超过 2 分钟。而且，当然，如果你在一次保存中有多个编译错误（你会的，因为你不想重新编译每个更改，
在相关的注释中，您似乎已经注意到 Salesforce 文档是相当自我祝贺的——嗯，从头到尾都是这样。即使是最深奥的技术参考文献中也没有提及常见错误，甚至没有提及给定 API 或功能的限制。都是“这是你能做的伟大的事情”，没有提到，“但你会想象它也会做___，但你错了！完全错了！” 文档从头到尾都感觉像是营销材料。我已经在这个环境中编程了 18 个多月了，但偶尔仍然很难找到基础知识，比如 API 参考。
Salesforce 不是一个灵活的环境。它不是一个快速开发的环境（至少与其他任何 Web 编程框架相比）。除了他们在教程中展示的那些玩具应用程序之外，这不是一个构建任何东西的好环境。拒绝吧。
我知道这个问题有点老了，但也值得看看这个问题Force.com 平台的缺点
我已经在这个平台上开发了一段时间，我完全同意 Ben 的看法。force.com 的“开发平台”有很多错误，我认为将其称为开发平台甚至不公平。
我们一直在努力解决工具支持，这很糟糕，部署支持，这很糟糕，甚至他们的技术支持，你猜对了，很糟糕。
我想说的主要一点是，salesforce 最初是一个 CRM，然后他们决定将“云平台”添加到他们的产品中。云平台非常适合扩展他们的 CRM 产品，如果你想做的是扩展 CRM，那么 force.com 环境会让你做得很好。
它不会让您做得很好的是放弃他们的 CRM 并让您轻松构建自己的完全自定义的应用程序。您仍然受制于他们的安全和用户模型，您的数据库中仍然有他们的标准对象，您的生产环境中仍然有他们的标准页面。可以这么说，没有“文件-> 新项目”。
另外，其他人提到它是“基于java的”。这并不意味着您可以在其中运行 java 代码。这意味着他们窃取了一些 java 并将其混为一谈，使其看起来像 java，但实际上并非如此......这真的很烦人，因为您不能只获取一组 java 库并将其导入到他们的云中......因此，如果您想做解析 JSON 之类的事情……您将自己编写。
总而言之，我会像瘟疫一样避开 force.com 平台。
听听本。不完全是。听听本。Salesforce 是一个绝对痛苦的世界。Salesforce 唯一的优点是他们的营销团队。
我真的不能告诉你你会以多快的速度达到边缘情况——但我可以告诉你，它不同于我做过的任何其他开发。创建一个可行的解决方案所需的实施时间——以及快速迭代解决方案以供业务发起人评估的能力是我所经历过的任何环境所无法比拟的。
Apex 代码基于 Java，具有特定于平台的差异。但是，有些事情不能通过代码完成。制作一个完整的应用程序所需的声明性（基于屏幕）和基于代码的实现的组合一开始很难让您理解。
由于环境的多租户性质，存在“管理者限制”，可防止资源被单个组织垄断。这限制了您在插入和更新触发器等方面的实现选项。
部署您的应用程序也是一种非常不同的体验。
查看 iTunes 上作为视频播客提供的开发人员培训（Dev 501）：http: //itunes.apple.com/WebObjects/MZStore.woa/wa/viewPodcast ?id=325668840 您将能够准确地看到我的内容我在谈论。
似乎这里的大多数答案都是否定的，我想说责备平台总是比责备自己的经验不足更容易。
对我来说有一个学习曲线，这很令人沮丧（来自 Java 背景）。语法相似，但范式非常不同。经过一番努力后，我设法构建了由数以万计用户使用的应用程序，这些应用程序可以完美扩展、易于管理和保护，并且包含了目前几乎所有的传统编程架构，包括 OOP、MVC 和许多其他“四人帮”设计模式。
如果您希望我指出示例代码或构建在平台上的大型应用程序的方向，我很乐意为您提供帮助。
在另一个 stackoverflow 线程中查看我的答案：Force.com 的缺点：
尽管线程很旧，但我最近还是回答了这个问题，因为我只是想借此机会说出该平台有多烦人。这些想法非常流行。
我建议，如果您确实计划使用该平台做任何事情，请确保您的一些团队成员获得 Apex 认证。一般来说，我强烈建议完全避免使用该平台，直到他们认真解决开发人员体验方面的问题以及存在特定且非常简单的业务案例时。
我给这个平台的昵称是“Little Ease”，以伦敦的一个 4x4 酷刑室命名，在那里你无法向任何一个方向扩展自己。你会不断地达到极限。
这也是一篇较旧的博客文章：
http://suprablog.com/index.php/2010/02/25/salesforce-the-astonshingly-powerful-little-ease-platform/
我没有在 Salesforce 的 .Net 方面进行开发，我确实为一个非常大的 Salesforce 安装创建了一些内部添加。
我可以说的是，系统中的开发工具可能会令人困惑，我一直遇到的最大瓶颈（在开发时）是为我想要的查询获取正确的语法。（警告，这是在 2007 年）
您可以使用 Salesforce 做伟大而令人惊奇的事情。唯一的问题是，据我估计，对于许多非平凡的系统和类似的功能，总拥有成本（整个 SDLC）很容易比 dotNET 和传统 RDBMS（如 SQL Server）高 3-10 倍. 为什么要为同样的结果付出那么多？