salesforce.com和Apex是什么样的应用程序开发平台?

时间:2009-05-14 08:58:38

标签: .net rad salesforce

我最近发现,在遇到Morrison的Case Study之后,salesforce.com不仅仅是一个在线CRM,他们开发了一个工作管理应用程序。我一直在试图在平台上重新创建我们自己的Works Management系统。

我的背景是微软和.Net,显而易见的第一选择是asp.net。然而,我真的只有.net经验,而我的经理有更多传统的Synergy编程背景,我自学成才,正在考虑评估其他RAD选项(例如Ironspeed)。

业务的性质是主要的2-5个并行建筑类型合同,每个合同运行3 - 5年,每个合同需要15-50个系统用户。传统上我们使用基于角色的Works Mangement系统来处理所有事情,并为每个合同调整它。面对它的Salesforce许可模式适合这种灵活性,但我担心开发灵活性/学习曲线以及围绕锁定的所有问题。对网络上的平台似乎没有太多中立的冷静分析,而不是salesforce自己的材料/博客

与更传统的.Net路线相比,有没有人在salesforce上开发应用程序的经验?

8 个答案:

答案 0 :(得分:50)

除了最简单的应用程序之外,Salesforce对于开发任何东西都是一种相当痛苦的经历。 Salesforce对于想要开发的内容有一个非常具体的想法,如果您的应用程序不在这些范围内,请明确指出!

调控器限制实际上非常可怜:16级递归,1兆堆,从查询返回的不超过200个对象,在一次调用中不超过20个查询。一次调用10个Web标注,单个列表中有1000个项目,然后继续。最终的结果是,你想出一个限制的任何聪明都会与另一个限制相悖。

一旦达到一定的规模,您将花费所有时间围绕这些限制进行编码。语言Apex并不真正支持任何有意义的继承。即使看似简单的任务最终会花费几天时间遇到新的且显然是任意的限制,例如,Apex中的所有对象都继承自SObject;但是,不允许实例化通用SObject的集合,这使得构建有用的实用程序库几乎不可能。复杂(甚至相当简单)的数据库连接是不可能的。

Salesforce的工具和支持也非常薄弱。它们不值得信任,难以用于真正的开发过程。部署是一场噩梦,因为这些工具在解决复杂的依赖性问题时遇到了巨大的困难,而且在正常开发过程中创建的众多实体无法以编程方式部署。其他一些小功能也很令人愉快,例如语言不区分大小写,但IDE区分大小写。没有重构工具可以说,所以你得到了静态类型语言的所有痛苦,没有任何所谓的好处。保存/编译时间很长 - 我看到频率超过2分钟的时间。当然,如果你在一次保存中有多个编译错误(并且你会,因为你不想重新编译每次更改,那些2分钟的等待......)你一次只会得到一个错误!

在相关的说明中,您似乎注意到Salesforce文档是相当自我祝贺的 - 好吧,就像那样一直向下。即使是对于常见错误甚至是给定api或特征的限制的最深刻的技术参考,也没有任何提及。这就是“这是你能做的伟大事情”而没有提及,“但你会想象它也会做___,但你错了!错了!”文档真正感觉就像营销材料一样。我已经在这个环境中编程了18个月以上,并且偶尔也很难找到基础知识,比如API参考。

Salesforce不是一个灵活的环境。它不是一个快速开发的环境(至少与其他任何网络编程框架相比)。除了他们在教程中展示的那些玩具应用程序之外,构建除了玩具应用程序以外的任何东说不。

答案 1 :(得分:12)

我知道这些问题有点陈旧,但也值得一看这个问题Disadvantages of the Force.com platform

我已经在平台上开发了一段时间,我不能同意Ben的观点。 “开发平台”是force.com的错误,我认为把它称为开发平台是不公平的。

我们一直在努力提供工具支持,这是非常糟糕的部署支持,这很糟糕甚至是他们的技术支持,你猜对了,很糟糕。

我想说的主要观点是,salesforce开始作为CRM,然后他们决定将“云平台”添加到他们的产品中。云平台,非常适合扩展他们的CRM产品,如果您想要做的是扩展CRM,那么force.com环境将让您做得很好。

它不会让你做得很好就是抛弃了他们的CRM,让你轻松地构建自己的完全自定义应用程序。您仍然依赖于他们的安全性和用户模型,您仍然会在数据库中拥有他们的标准对象,并且您仍然可以在生产环境中使用他们的标准页面。没有“文件 - >新项目”可以这么说。

另外,有人提到它是“基于java的”。这并不意味着你可以在那里运行java代码。这意味着他们偷了一些java并把它搞砸了看起来像java但真的不是......这真的很烦人,因为你不能只抓住一组java库并将它导入到他们的云中......所以,如果你想做一些像解析JSON的事情......那你就自己写一下。

Ovearall,我会像瘟疫一样避开force.com平台。

答案 2 :(得分:9)

听Ben。不完全是。听Ben。 Salesforce是一个绝对痛苦的世界。 Salesforce唯一的好处就是他们的营销团队。

答案 3 :(得分:8)

我无法真实地告诉你你有多快会遇到边缘情况 - 但我可以告诉你,这与我曾经做过的任何其他开发都不同。创建可行解决方案所需的实施时间 - 以及快速迭代供业务赞助商评估的解决方案的能力是我所经历过的任何环境所无法比拟的。

Apex代码基于Java,具有特定于平台的差异。但是,有些事情无法通过代码完成。创建完整应用程序所需的声明式(基于屏幕)和基于代码的实现的组合很难首先解决。

由于环境的多租户性质,存在“州长限制”,其阻止资源被单个组织垄断。这限制了插入和更新触发器等实现选项。

部署您的应用程序也是一种非常不同的体验。

在iTunes上查看可用作视频播客的开发者培训(Dev 501):http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=325668840您将能够看到我正在谈论的内容。

答案 4 :(得分:6)

似乎这里的大部分答案都是否定的,我会说,责备平台总是比责备你自己的经验更容易。

我有一个学习曲线,这令人沮丧(来自Java背景)。语法类似,但范式非常不同。经过一段时间的努力,我已经成功构建了成千上万用户使用的应用程序,这些应用程序完美地扩展,易于管理和安全,并且几乎包含了目前所包含的所有传统编程体系结构,包括OOP,MVC和许多其他“四人帮”的设计模式。

如果您希望我指出示例代码的方向,或者在平台上构建的宏大应用程序,我很乐意帮助您。

答案 5 :(得分:3)

在另一个stackoverflow线程中查看我的答案:Force.com的缺点:

Disadvantages of the Force.com platform

我最近回答说,虽然线程已经老了,因为我只是想抓住机会听出平台有多烦人。那些想法是最新的。

我建议如果您计划在平台上做任何事情,请确保您的一些团队成员获得Apex认证。总的来说,我强烈建议完全避开平台,直到他们认真地解决开发人员的体验方面以及有特定和非常简单的业务案例。

我对该平台的昵称是“Little Ease”,以伦敦4x4酷刑室命名,你无法向任何一个方向伸展自己。你会不断地达到极限。

以下是一篇较旧的博文:

http://suprablog.com/index.php/2010/02/25/salesforce-the-astonishingly-powerful-little-ease-platform/

答案 6 :(得分:2)

我还没有在Salesforce的.Net方面开发过,我确实为一个非常大的Salesforce安装创建了一些内部补充。

我可以说的是,系统中的开发工具可能会令人困惑,而我在开发时遇到的最大瓶颈就是为我想要的查询获取正确的语法。 (告诫,这是在2007年)

答案 7 :(得分:1)

您可以使用Salesforce做出精彩而令人惊叹的事情。唯一的问题是,在我对许多非平凡系统和类似功能的估计中,总体拥有成本(整个SDLC)比使用dotNET和传统的RDBMS(如SQL Server)容易高3到10倍。为什么要为同样的结果支付更多?