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