salesforce.com 和 Apex 作为应用程序开发平台是什么样的？
最近，在接触 Morrison 的 案例研究，其中他们开发了一个工程管理应用程序。 我一直在尝试在平台上重新创建我们自己的工作管理系统。
我的背景是 Microsoft 和 .Net，显然第一个选择是 asp.net。 然而，只有我自己具有 .net 经验，而我的经理则具有更传统的 Synergy 编程背景，而且我是自学的，并且正在考虑评估其他 RAD 选项（例如 Ironspeed）。
该业务的性质主要是 2-5 个并发建设类型合同，每个合同运行 3-5 年，每个合同需要 15-50 个系统用户。 传统上，我们使用基于角色的作品管理系统来处理所有事情，并针对每个合同进行调整。 从表面上看，Salesforce 许可模式适合这种灵活性，但我担心开发灵活性/学习曲线以及围绕锁定的所有问题。 除了 salesforce 自己的材料/博客之外，网络上似乎没有太多对该平台的中立冷静分析。
与更“传统”的 .Net 路线相比，有没有人有在 salesforce 上开发应用程序的经验？
I have recently discovered that salesforce.com is much more than an online CRM after coming across a Morrison's Case Study in which they develop a works management application. I've been trying it out with a view to recreating our own Works Management system on the platform.
My background is in Microsoft and .Net, and the obvious 1st choice would be asp.net. However, there's only really myself with .net experience and my manager with a more legacy Synergy programming background, and I am self taught and am looking at evaluating other RAD options (eg Ironspeed).
the nature of the business is in the main 2-5 concurrent construction type contracts that run for 3-5 yrs each, each requiring 15-50 system users. Traditionally we have used our character based Works Mangement system for everything and tweaked it for each contract. The Salesforce licensing model on the face of it suits this sort of flexibilty, but I'm worried about the development flexibilty/learning curve and all the issues that surround lock-in. There doesn't seem to be much neutral sober analysis of the platform on the web that isn't salesforce's own material/blogs
Has anyone any experience of developing an application on salesforce as compared to the more 'traditional' .Net route?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
我确实无法告诉您遇到边缘情况的速度有多快，但我可以告诉您，这与我做过的任何其他开发都不一样。 创建可行的解决方案所需的实施时间以及快速迭代解决方案以供业务发起人评估的能力是我经历过的任何环境都无法比拟的。
Apex 代码基于 Java，具有特定于平台的差异。 但是，有些事情无法通过代码完成。 制作完整的应用程序所需的声明式（基于屏幕）和基于代码的实现的组合一开始很难让您理解。
由于环境的多租户性质，存在“调控器限制”，可防止资源被单个组织垄断。 这限制了您在插入和更新触发器等方面的实现选项。
部署应用程序也是一种非常不同的体验。
查看 iTunes 上以视频播客形式提供的开发人员培训 (Dev 501)：http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=325668840 您将能够准确地看到我在说什么。
I can't really tell you how fast you'll hit the edge cases -- but I can tell you that it's unlike any other development I've ever done. The implementation time required to create a workable solution -- and the ability to rapidly iterate a solution for business sponsors to evaluate are unmatched by any environment I've experienced.
The Apex code is based on Java, with platform specific differences. However, some things can't be done through code. The combination of declarative (screen based) and code based implementation required to craft a complete application is hard to wrap your head around at first.
Due to the multi-tenant nature of the environment, there are 'governor limits' which prevent resources from being monopolized by a single organization. This restricts your implementation options in things like insert and update triggers.
Deploying your application is a very different experience as well.
Check out the developer training (Dev 501) available as video podcast on iTunes: http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=325668840 You'll be able to see exactly what I'm talking about.
我知道这个问题有点老了，但也值得看看这个问题 Force.com 平台的缺点
我在该平台上开发已经有一段时间了，我非常同意 Ben 的观点。 Force.com这个“开发平台”有太多错误，我真的认为称其为开发平台并不公平。
我们一直在努力解决工具支持，这很糟糕，部署支持，这很糟糕，甚至他们的技术支持，你猜对了，很糟糕。
我想说的主要一点是，Salesforce 最初是作为 CRM 开始的，然后他们决定将“云平台”添加到他们的产品中。 不过，云平台主要用于扩展他们的 CRM 产品，如果您想要扩展 CRM，那么force.com 环境将让您很好地做到这一点。
它不会让您做得很好的是放弃他们的 CRM 并让您轻松构建自己的完全自定义应用程序。 您仍然受到他们的安全和用户模型的束缚，您的数据库中仍然有他们的标准对象，并且您的生产环境中仍然有他们的标准页面。 可以这么说，没有“文件 -> 新项目”。
另外，其他人提到它是“基于java的”。 这并不意味着您可以在那里运行 java 代码。 这意味着他们窃取了 java 的一些部分，并将其弄得像 java，但实际上不是......这真的很烦人，因为你不能仅仅获取一组 java 库并将其导入到他们的云中......所以如果你想做一些像解析 JSON 这样的事情......你需要自己编写。
总的来说，我会像躲避瘟疫一样避开force.com 平台。
I know this questions is a little old, but it'd also be worth looking at this question Disadvantages of the Force.com platform
I've been developing on the platform for a while and I couldn't agree more with Ben. There is so much wrong with the "development platform" that is force.com that I don't really think it's even fair to call it a development platform.
We've struggled with tooling support, which is terrible, deployment support, which is terrible and even their tech support which is, you guessed it, terrible.
The main point I want to make tho is that salesforce started off as a CRM and then they decided to add the "cloud platform" to their offering. The cloud platform tho, is heavily geared towards extending their CRM product and if what you're wanting to do is extend the CRM, then the force.com environment will let you do that nicely.
What it won't let you do nicely is ditch their CRM and let you build your own completely custom application easily. You are still tied into their security and user model, you will still have their standard objects in your database and you will still have their standard pages in your production environment. There is no "File -> New Project" so to speak.
Also, someone else mentioned it's "java based". This doesn't mean you can run java code in there. It means they've stolen some bits of java and bastardized it to look like java but really isn't... which is really annoying because you can't just grab a set of java libraries and import it into their cloud... so if you want to do something like parsing JSON... you're gonna be writing that yourself.
Ovearall, I'd avoid the force.com platform like the plague.
听本。 不完全是。 听本。 Salesforce 绝对是一个充满痛苦的世界。 Salesforce 唯一好的地方是他们的营销团队。
Listen to Ben. No really. Listen to Ben. Salesforce is an absolute world of pain. The only thing good about Salesforce is their marketing team.
似乎这里的大多数答案都是负面的，我想说，责怪平台总是比责怪你自己的经验不足更容易。
对我来说有一个学习曲线并且令人沮丧（来自 Java 背景）。 语法相似，但范式非常不同。 经过一番努力之后，我成功构建了可供数万名用户使用的应用程序，这些应用程序可以完美扩展、易于管理和安全，并且包含目前所采用的几乎所有传统编程架构，包括 OOP、MVC 和许多其他“四人帮”设计模式。
如果您希望我向您指出示例代码或在该平台上构建的大型应用程序的方向，我很乐意为您提供帮助。
It seems most of the answers on here are negative, and I'd say that it's always easier to blame a platform than it is to blame your own inexperience.
There was a learning curve for me and it was frustrating (coming from a Java background). The syntax was similar but the paradigm very different. After battling it out for a bit I've managed to build apps used by tens of thousands of users that scale perfectly, are easy to manage and secure, and that incorporate almost all traditional programming architectures currently embraced including the basics of OOP, MVC and many of the other 'Gang Of Four' design patterns.
If you'd like me to point you in the direction of example code, or grand applications built on the platform I'd be happy to help you out.
我还没有在 Salesforce 的 .Net 方面进行开发，我确实为一个非常大的 Salesforce 安装创建了一些内部添加内容。
我能说的是，系统内的开发工具可能会令人困惑，而我一直面临的最大瓶颈（在开发时间）是为我想要的查询获取正确的语法。 （注意，这是 2007 年的事）
I haven't developed on the .Net side of Salesforce, I did create a few in house additions to a very large Salesforce installation.
What I can say about it is that the development tools within the system can be confusing and the largest bottleneck I always had (in development time) was to get the correct syntax for the queries I wanted. (caveat, this was back in 2007)
您可以使用 Salesforce 做出伟大而令人惊奇的事情。 唯一的问题是，据我估计，对于许多重要的系统和同类功能，总拥有成本（整个 SDLC）很容易比使用 dotNET 和 SQL Server 等传统 RDBMS 的成本高 3-10 倍。 为什么要为同样的结果付出那么多？
You can do great and amazing things with Salesforce. The only problem is that in my estimation for many non-trivial systems and like-for-like functionality total cost of ownership (whole SDLC) is easily 3-10 times higher than what it would be with dotNET and a traditional RDBMS like SQL Server. Why pay that much more for the same result?
请参阅我在另一个 stackoverflow 线程中的回答：Force.com 的缺点：
缺点 我最近回答了Force.com 平台，
尽管该帖子已经很旧了，因为我只是想借此机会表达一下这个平台有多么烦人。 这些想法非常流行。
我建议，如果您确实计划使用该平台做任何事情，请确保您的一些团队成员获得了 Apex 认证。 总的来说，我强烈建议完全避免使用该平台，直到他们认真解决开发人员体验方面的问题以及存在特定且非常简单的业务案例。
我给这个平台起的昵称是“Little Ease”，以伦敦的一个四轮驱动酷刑室命名，在那里你无法向任何一个方向延伸自己。 你会不断达到极限。
这也是一篇较旧的博客文章：
http://suprablog.com/index.php/2010/02/25/salesforce-the-astonishingly-powerful-little-ease-platform/
See my answer in another stackoverflow thread: Disadvantages of Force.com:
Disadvantages of the Force.com platform
which I answered recently even though the thread was old because I just wanted to take the chance to sound off on how annoying the platform is. Those thoughts are very current.
I would suggest that if you do plan on doing anything with the platform, make sure some of your team members are Apex certified. In general, I would strongly recommend avoiding the platform entirely until they seriously address the developer experience side of things and where there are specific and very simple business cases.
My nickname for the platform is "Little Ease", named after a 4x4 torture chamber in London where you couldn't extend yourself in any one direction. You'll hit limits constantly.
Here's an older blog post, too:
http://suprablog.com/index.php/2010/02/25/salesforce-the-astonishingly-powerful-little-ease-platform/
除了最简单的应用程序之外，Salesforce 的开发体验是相当痛苦的。 Salesforce 对于人们想要开发的内容有一个非常具体的想法，如果您的应用程序没有很好地落在这些界限内，请避开！
调控器的限制确实很可怜：16 级递归、1 meg 堆、一次查询返回的对象不超过 200 个、一次调用不超过 20 个查询。 一次调用 10 个 Web 标注，单个列表中 1000 个项目，等等。 最终的结果是，你为绕过一个限制而想出的任何聪明才智都会与另一个限制发生冲突。
一旦达到一定规模，您所有的时间都将花在围绕这些限制进行编码上。 Apex 语言并不真正支持任何有意义的继承。 即使看似简单的任务，当遇到新的且明显任意的限制时，最终也会花费数天的时间，例如，Apex 中的所有对象都继承自
SObject； 但是，不允许实例化通用SObject的集合，这使得构建有用的实用程序库几乎不可能。 复杂（甚至相当简单）的数据库连接是不可能的。Salesforce 的工具和支持也极其薄弱。 它们不值得信赖并且难以用于实际的开发过程。 部署是一场噩梦，因为这些工具在解决复杂的依赖性问题方面存在巨大困难，并且在正常开发过程中创建的许多实体根本无法以编程方式部署。 其他小功能也很令人愉快，例如语言不区分大小写，但 IDE 区分大小写。 没有重构工具可言，因此您会遭受静态类型语言的所有痛苦，却没有任何所谓的好处。 而且保存/编译时间很长——我经常看到超过 2 分钟的时间。 当然，如果你在一次保存中出现多个编译错误（你会的，因为你不想重新编译每一个更改，等待 2 分钟......），你一次只会收到一个错误！
在相关说明中，您似乎已经注意到 Salesforce 文档相当自我祝贺——嗯，自始至终都是这样。 即使是最深奥的技术参考资料中也没有提及常见错误，甚至没有提及给定 API 或功能的限制。 都是“这是你能做的伟大的事情”，却没有提及，“但你会想象它也能做___，但你错了！大错特错了！” 该文档确实感觉像是自始至终的营销材料。 我已经在这个环境中编程了 18 个多月了，但有时仍然很难找到基础知识，比如 API 参考。
Salesforce 不是一个灵活的环境。 它不是一个快速开发环境（至少与任何其他网络编程框架相比）。 除了像他们在教程中展示的玩具应用程序之外，这不是构建任何其他东西的好环境。 拒绝吧。
Salesforce is a rather painful experience for developing anything but the most simple applications. Salesforce has a very specific idea of what one would want to develop, and if your application isn't well within those boundaries, steer clear!
The governor limits are really quite pitiful: 16 level recursion, 1 meg heap, no more than 200 objects returned from a query, no more than 20 queries in one invocation. 10 web callouts in one invocation, 1000 items in a single list, and they go on. The ultimate result is that any cleverness you come up with to get around one limit runs afoul of another one.
Once you reach certain size, all your time will be spent on coding around these limitations. The language, Apex, doesn't really support any meaningful inheritance. Even seemingly simple tasks end up taking days when one encounters new and apparently arbitrary limitations, for example, all objects in Apex inherit from
SObject; however, it is not allowed to instantiate a collection of genericSObjects, making it all but impossible to build useful utility libraries. Complex (even rather simple) database joins are not possible.The tooling and support for Salesforce are also extremely weak. They are untrustworthy and difficult to use for real development processes. Deployment is a nightmare, since the tools have enormous difficulty working out complex dependency issues, and numerous entities that one will create in the course of normal development simply CANNOT be deployed programatically. Other little features are delightful as well, such as the fact that the language is case insensitive, but the IDE is case sensitive. There are no refactoring tools to speak of, so you get all the pain of a statically typed language, with none of the purported benefits. And the save/compile time is high- I see times of over 2 minutes with frequency. And, of course, if you have multiple compile errors in one save (and you will, since you won't want to be recompiling every change, with those 2 minute waits...) you'll only get one error at a time!
On a related note, you seem to have noticed that the Salesforce documentation is rather self-congratulatory-- well, it's like that ALL the way down. There is no mention anywhere in even the most deep-dark technical references of the common errors, or even the limitations of a given api or feature. It's all "here's the great thing you can do" and no mention of, "but you would imagine it would also do ___, but you'd be wrong! Dead wrong!" The documentation truly feels like marketing material all the way down. I've been programming in this environment for 18+ months now, and still occasionally have a hard time finding basics, like API reference.
Salesforce is not a flexible environment. It is not a rapid-development environment (at least compared to any other web-programming framework out there). It is not a good environment to build anything other than toy applications like those they show in their tutorials. Just say no.