mho*_*ers 37 .net salesforce rad
我最近发现,在经历了Morrison的案例研究后,salesforce.com不仅仅是一个在线CRM ,他们开发了一个工作管理应用程序.我一直在试图在平台上重新创建我们自己的Works Management系统.
我的背景是微软和.Net,显而易见的第一选择是asp.net.然而,我真的只有.net经验,而我的经理有更多传统的Synergy编程背景,我自学成才,正在考虑评估其他RAD选项(例如Ironspeed).
业务的性质是主要的2-5个并行建筑类型合同,每个合同运行3 - 5年,每个合同需要15-50个系统用户.传统上我们使用基于角色的Works Mangement系统来处理所有事情,并为每个合同调整它.面对它的Salesforce许可模式适合这种灵活性,但我担心开发灵活性/学习曲线以及围绕锁定的所有问题.网站上的平台似乎没有太多中立的清醒分析,而不是salesforce自己的材料/博客
与更"传统"的.Net路线相比,有没有人在salesforce上开发应用程序的经验？
Ben*_*Ben 51
除了最简单的应用程序之外,Salesforce对于开发任何东西都是相当痛苦的经历.Salesforce对于想要开发的内容有一个非常具体的想法,如果您的应用程序不在这些范围内,请明确指出!
调控器限制实际上非常可怜:16级递归,1兆堆,从查询返回的不超过200个对象,在一次调用中不超过20个查询.一次调用10个Web标注,单个列表中有1000个项目,然后继续.最终的结果是,你想出一个限制的任何聪明都会与另一个限制相冲突.
一旦达到一定的大小,您将花费所有时间来围绕这些限制进行编码.语言Apex并不真正支持任何有意义的继承.即使看似简单的任务最终会花费几天时间遇到新的且显然是任意的限制,例如,Apex中的所有对象都会继承SObject; 但是,不允许实例化泛型SObjects 的集合,使得构建有用的实用程序库几乎不可能.复杂(甚至相当简单)的数据库连接是不可能的.
Salesforce的工具和支持也非常薄弱.它们不值得信任,难以用于真正的开发过程.部署是一场噩梦,因为这些工具在解决复杂的依赖性问题时遇到了巨大的困难,而且在正常开发过程中创建的众多实体无法以编程方式部署.其他一些小功能也很令人愉快,例如语言不区分大小写,但IDE区分大小写.没有重构工具可言,所以你得到了静态类型语言的所有痛苦,没有任何所谓的好处.保存/编译时间很长 - 我看到频率超过2分钟的时间.当然,如果你在一次保存中有多个编译错误(并且你会,因为你不想重新编译每个更改,那些2分钟的等待......)你一次只会得到一个错误!
在相关的说明中,您似乎已经注意到Salesforce文档是相当自我祝贺的 - 好吧,它就像是一直向下.即使是对于常见错误甚至是给定api或特征的限制的最深刻的技术参考,也没有任何提及.这就是"这是你能做的伟大事情"而没有提及,"但你会想象它也会做___,但你错了!错了!" 文档真正感觉就像营销材料一样.我已经在这个环境中编程了18个月以上,并且偶尔也很难找到基础知识,比如API参考.
Salesforce不是一个灵活的环境.它不是一个快速开发的环境(至少与其他任何网络编程框架相比).除了他们在教程中展示的那些玩具应用程序之外,构建除了玩具应用程序以外的任何东 拒绝吧.
lom*_*axx 12
我知道这个问题有点陈旧,但也值得一看这个问题Force.com平台的缺点
我已经在平台上开发了一段时间,我和Ben完全同意."开发平台"是force.com的错误,我认为把它称为开发平台是不公平的.
我们一直在努力工具支持,这是可怕的,部署支持,这是可怕的,甚至他们的技术支持,你猜对了,可怕.
我想说的主要观点是,salesforce开始作为CRM,然后他们决定将"云平台"添加到他们的产品中.云平台,非常适合扩展他们的CRM产品,如果您想要做的是扩展CRM,那么force.com环境将让您做得很好.
什么它不会让你做得很好是放弃他们的CRM,让你轻松地建立自己的完全自定义应用程序.您仍然依赖于他们的安全性和用户模型,您仍然会在数据库中拥有他们的标准对象,并且您仍然可以在生产环境中使用他们的标准页面.没有"文件 - >新项目"可以这么说.
此外,其他人提到它是"基于java".这并不意味着你可以在那里运行java代码.这意味着他们偷了一些java并把它搞砸了看起来像java但真的不是......这真的很烦人,因为你不能只抓住一组java库并将它导入到他们的云中......所以,如果你想做一些像解析JSON的事情......你会自己写的.
Ovearall,我会像瘟疫一样避开force.com平台.
我真的不能告诉你你有多快会遇到边缘情况 - 但我可以告诉你,这与我曾经做过的任何其他开发都不同.创建可行解决方案所需的实施时间 - 以及快速迭代业务发起人评估解决方案的能力是我所经历的任何环境所无法比拟的.
Apex代码基于Java,具有特定于平台的差异.但是,有些事情无法通过代码完成.创建一个完整的应用程序所需的声明式(基于屏幕)和基于代码的实现的组合很难首先解决.
由于环境的多租户性质,存在"州长限制",其阻止资源被单个组织垄断.这限制了插入和更新触发器等实现选项.
部署应用程序也是一种非常不同的体验.
查看开发者培训(Dev 501),可在iTunes上以视频播客的形式获取:http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewPodcast？id = 325668840 您将能够看到我到底是什么我在谈论.
小智 6
似乎这里的大部分答案都是否定的,我会说,责备平台总是比责备自己的经验更容易.
对我来说有一个学习曲线,它令人沮丧(来自Java背景).语法类似,但范式非常不同.争夺它了一点后,我已经成功地建立由完美扩展,易于管理和安全的用户数以万计使用的应用程序,并结合了几乎所有传统的编程架构目前接受包括OOP,MVC和的基础知识许多其他"四人帮"的设计模式.
如果您希望我指出示例代码的方向,或者在平台上构建的宏大应用程序,我很乐意帮助您.
我还没有在 Salesforce 的 .Net 方面进行开发，我确实为一个非常大的 Salesforce 安装创建了一些内部添加内容。
我能说的是，系统内的开发工具可能会令人困惑，而我一直面临的最大瓶颈（在开发时间）是为我想要的查询获取正确的语法。（注意，这是 2007 年的事）
| 归档时间： |
|
| 查看次数： |
11417 次 |
| 最近记录： |