Force.com 플랫폼의 단점

Force.com 플랫폼의 단점

---

우리는 현재 Force.com 플랫폼을 개발 플랫폼으로 사용하고 있으며 영업 담당자와 force.com 웹 사이트는 왜 이것이 세계 최고의 플랫폼인지에 대한 이유로 가득 차 있습니다. 하지만 제가 찾고있는 것은 그러한 플랫폼을 사용하는 데있어 몇 가지 실질적인 단점입니다.

---

시작하는 데 10 가지가 있습니다.

1. Apex는 독점 언어입니다. force.com Eclipse 플러그인 외에는 리팩토링, 코드 분석 등과 같은 도구가 거의 없거나 전혀 없습니다.
2. Apex는 다른 언어보다 뒤 떨어지는 것으로 간주되는 Java 5에서 모델링되었으며 도구없이 (# 1 참조) 매우 번거로울 수 있습니다.
3. 배포는 여전히 많은 문제와 수동 단계로 상당히 수동적입니다. 이 상황은 시간이 지남에 따라 서서히 개선되고 있지만 자동화 된 배포에 익숙하다면 실망 할 것입니다.
4. Apex에는 패키지 / 네임 스페이스가 없습니다. 모든 클래스, 인터페이스 등은 서버의 한 폴더에 있습니다. 이로 인해 코드가 훨씬 덜 구성되고 클래스 / 인터페이스 이름이 이름 충돌을 방지하고 컨텍스트를 제공하기 위해 반드시 길어집니다. 이것은 저의 가장 큰 불만 중 하나이며,이 이유만으로는 force.com을 구축하기로 자유롭게 선택하지 않을 것입니다.
5. "force.com IDE", 일명 force.com eclipse 플러그인은 매우 느립니다. 클래스 파일, 텍스트 파일 등의 파일을 저장하는 데 일반적으로 조직에있는 개체, 데이터 유형, 클래스 파일 등의 수에 따라 최소 5 초, 때로는 최대 30 초가 소요됩니다. 저장은 또한 차단 작업이며 컴파일뿐만 아니라 로컬 프로젝트와 서버의 전체 동기화가 필요합니다. Java 또는 .NET보다 느립니다.
6. 온라인 개발자 커뮤니티는 건강하지 않은 것 같습니다. 많은 포럼 게시물이 답변되지 않거나 해결되지 않은 것으로 나타났습니다. 나는 이것이 salesforce.com이 사용하는 포럼 소프트웨어와 관련이 있다고 생각합니다.
7. Apex의 데이터 액세스 DSL은 많이 필요합니다. (N) Hibernate, JPA 등과 같이 원격으로 경쟁하지도 않습니다.
8. Apex / VisualForce에서 앱을 개발하는 것은 주지사 제한 엔지니어링의 연습입니다. 프로그래머 시간의 절반은 수많은 거버너 제한 및 visualforce보기 상태 제한과 같은 기타 문제를 피하기 위해 최적화하는 데 소요됩니다. 처음부터 효율적인 코드를 작성하면이 문제가 발생하지 않을 것이라고 주장 할 수 있으며, 이는 어느 정도 사실입니다. 그러나 세션에서 x 개 이상의 쿼리를 작성하거나 x 개 이상의 레코드를 반복하는 등의 유효한 이유가있는 경우가 많습니다.
9. 저장-> 컴파일-> 실행주기는 매우 느립니다. 사소한 CSS 또는 자바 스크립트 변경 테스트와 같은 작업을 수행하기 위해 전체 정적 리소스 번들을 압축하고 업로드하는 작업이 포함되는 경우.
10. 일반적으로 오픈 소스라는 이점이없는 신생 플랫폼의 고통입니다. 플랫폼에서 버그를 확인 및 / 또는 수정할 수있는 방법이 없습니다. 그들은 IdeaExchange에 게시하라고 말합니다. 네, 행운을 빕니다.

고지 사항 / 공개 : force.com과 같은 호스팅 플랫폼에는 많은 이점이 있습니다. Force.com은 정기적으로 플랫폼을 향상시킵니다. 내가 좋아하는 것들이 많이 있습니다. force.com에서 돈을 벌어

---

몇 가지 답변을 받았지만 플랫폼의 다양한 주지사 한계를 극복하는 데 얼마나 많은 시간이 낭비되는지 반복하고 싶습니다. 특정 수준에서 플랫폼을 좋아하는만큼 일반적인 애플리케이션 개발 플랫폼으로 강력하고 강력하게 반대 할 것을 강력히 권장합니다. 원하는 경우 매우 구성 가능하고 확장 가능한 CRM 응용 프로그램으로 좋습니다. 그들의 마케팅은 Force.com의 아이디어를 일반 개발 플랫폼으로 추진하는 데 탁월하지만 아직 멀지 않았습니다.

사람들이 언급하는 한계를 기준으로 코드를 작성하는 데있어 안정적인 플랫폼을 보유하고 큰 성능 및 안정성 문제를 피하는 효율성은 쉽게 낭비됩니다. 플랫폼에는 너무 많은 한계가있어 완전히 미쳐 버립니다. 이러한 제한은 사용자가 많을 때 적용되는 최고 수준의 제한이 아니며 거의 즉시 적용됩니다.

일반적으로 이러한 문제를 피할 수있는 기술이 있지만 실제 애플리케이션의 비즈니스 로직을 개발하는 동안에도 이러한 문제를 피할 수있는 전략을 찾는 것은 매우 어렵습니다.

개발자가 환경에 얼마나 비 친화적인지 간단히 이해하려면 위에서 언급 한 "디버깅 환경 부족"을 고려하십시오. 그것보다 더 나쁩니다. 디버그 로그에서 서버에 대한 최근 요청을 최대 20 개까지만 볼 수 있습니다. 따라서 응용 프로그램 내에서 개발할 때 "새로 만들기"디버그 요청을 만들고 이름을 선택하고 "저장"을 누르고 앱으로 다시 전환 한 다음 페이지를 새로 고치고 디버그 탭으로 돌아가서 찾아야합니다. 디버그 로그를 저장할 요청이 있으면 "찾기"를 눌러 찾고있는 텍스트를 검색하십시오. 디버그 출력을보기 위해 10 번 클릭하는 것과 같습니다. 사소 해 보일 수 있지만 개발자의 경험에 대한 관심과 고려가 얼마나 적은지 보여주는 예일뿐입니다.

개발 플랫폼에 대한 모든 것은 나중에 접목 된 것입니다. 그것이 무엇인지에 대해서는 놀랍지 만 대부분의 경우 전체 PITA입니다. 수행중인 작업을 정확히 알지 못하는 경우 (인증을 받았으며 Apex에 대해 매우 친밀하게 이해하고 있음) 다른 환경에서 수행하는 데 걸리는 시간의 10-20 배 이상이 쉽게 걸립니다. 당신이 전혀 성공할 수 있다면 말도 안되게 간단 할 것 같은 무언가.

주지사 한계는 실제로 그렇게 나쁩니다. 다양한 제한 (데이터베이스 쿼리, 반환 된 행, "스크립트 문", 향후 호출, 콜 아웃 등)의 조합 이 있으며이를 방지하기 위해 수행중인 작업을 정확히 알아야 합니다 . 예를 들어 개체에 계산 된 롤업 "수식"필드가 있고 하위 개체에 대한 트리거가있는 경우 상위 개체 트리거를 실행하고 제한에 대해 계산합니다. 그런 일은 시도하고 실패하는 고통스러운 과정을 거치기 전까지는 분명하지 않습니다.

당신은 하나의 제한을 피하기 위해 한 가지 시도를하고 "한도를 깨뜨리기"라는 끝없는 게임에서 다른 것을 치게 될 것입니다. 이 과정에서 전체 앱과 접근 방식을 대폭 다시 설계하고 모든 테스트 코드를 다시 작성해야합니다. 당신은 있어야합니다 실제로 매우 좋은 일이지만, 다른 기준을 모두 결합 생산에 배포하는 75 %의 테스트 코드 범위를 가지고, 그것은 부담이 매우이다. 실제로 일반 사용자 시나리오에서는 나오지 않는 테스트 코드를 작성하는 거버너 제한에 도달하지만 이로 인해 적용 범위를 달성 할 수 없습니다.

그것은 다른 많은 문제를 언급하지 않습니다. 포장은 당신이 기대하는 것이 아닙니다. 조직 관리자의 중요한 사용자 개입 및 구성 없이는 앱을 패키징하여 사용자에게 전달할 수 없습니다. AppExchange는 완전히 농담이며 앱을 나열하기 위해 5K를 충전하기 시작했습니다. 특히 트리거가있는 경우 데이터 로더를 사용하여 가져 오기가 어렵습니다. 한 단계에서 다른 조직 (예 : 개발 조직)으로 쉽게 다시 가져올 수있는 방식으로 관계를 포함하는 모든 데이터를 한 단계로 내보낼 수는 없습니다. 프로덕션에서 한 달에 한 번만 샌드 박스를 새로 고칠 수 있으며 예외는 없으며 계정 관리자에게 전화를 걸어 해당 기능을 잠금 해제하지 않는 한 기본적으로 새로 고침에 데이터를 포함 할 수 없습니다. 당신은 할 수 있습니다 t 사용자 지정 개체의 데이터를 대량 삭제합니다. 패키지 이름은 변경할 수 없습니다. 어떤 것들은 수많은앱을 배포하기 전에 데이터 백업과 같이 요청한 후 완료해야하는 일. 진행률 보고서가없고 정확히 언제 내보내기가 발생했는지 알지 못합니다. 데이터간에 관계가있는 경우 데이터의 동시성 문제가 있다는 점을 감안할 때 여러 개체를 한 번에 내보낼 수있는 "트랜잭션"과 같은 것이 없다는 점에서 심각한 데이터 무결성 문제가 있습니다. 이 중 일부를 용이하게하는 몇 가지 상용 도구가있을 수 있지만 이러한 도구는 막대한 예산이 없을 수도있는 일반 개발자가 사용할 수 없습니다.

다른 사람들이 여기서 말한 모든 것은 사실입니다. 파일을 저장하는 데 5 초에서 1 분까지 걸릴 수 있습니다.

I don't mean to be so negative because the platform is very cool in some ways and they're trying to do things in a multi-tenant environment that no one else is doing. It's a very innovative environment and powerful on some levels (I actually like VisualForce a lot), but give it another year or two. They're partnering with VMware, maybe that will lead to giving developers a bit more of a playpen rather than a jail cell to work in.

---

Here are a few things I can give you after spending a fair bit of time developing on the platform in the last fortnight or so:

1. There's no RESTful API. They have a soap based API that you can call, but there is no way of making true restful calls

2. There's no simple way to take their SObjects and convert them to JSON objects.

3. The visual force pages are ok until you want to customize them and then it's a whole world of pain.

4. Visual force pages need to be bound to SObjects otherwise there's no way to get the standard input fields like the datepicker or select list to work.

5. The eclipse plugin is ok if you want to work by yourself, but if you want to work in a large team with the eclipse plugin forget it. It doesn't handle synchronizing to and from the server, it crashes and it isn't really helpful at all.

6. THERE IS NO DEBUGGER! If you want to debug, it's literally debugged by system.debug statements. This is probably the biggest problem I've found

7. Their "MVC" model isn't really MVC. It's a lot closer to ASP.NET Webforms. Your views are tightly coupled to not only the models but the controllers as well.

8. Storing a large number of documents is not feasible. We need to store over 100gb's of documents and we were quoted some ridiculous figure. We've decided to implement our document storage on amazons S3 infrastructure

9. Even tho the language is java based, it's not java. You can't import any external packages or libraries. Also, the base libraries that are available are severely limited so we've found ourselves implementing a bunch of stuff externally and then exposing those bits as services that are called by force.com

10. You can call external SOAP or REST based services but the message body is limited to 100kb's so it's very restrictive in what you can call.

In all honesty, whilst there are potential benefits to developing on something like the force.com platform, for me, you couldn't use the force.com platform for true enterprise level apps. At best you could write some basic crud style applications but once you move into anything remotely complicated I'd be avoiding it like the plague.

---

Wow- there's a lot here that I didn't even know were limitations - after working on the platform for a few years.

But just to add some other things...

The reason you don't have a line-by-line debugger is precisely because it's a multi-tenant platform. At least that's what SFDC says - it seems like in this age of thread-rich programming, that isn't much of an excuse, but that's apparently the reason. If you have to write code, you have "System.debug(String)" as your debugger - I remember having more sophisticated server debugging tools in Java 1.2 about 12 years ago.

Another thing I really hate about the system is version control. The Spring framework is not used for what Spring is usually used for - it's really more off a configuration tool in SFDC rather than version control. SFDC provides ZERO version-control.

You can find yourself stuck for days doing something that should seem so ridiculously easy, like, say, scheduling a SFDC report to export to a CSV file and email to a list of recipients... Well, about the easiest way to do that is create a custom object with a custom field, with a workflow rule and a Visualforce email template... and then for code you need to write a Visualforce component that streams the report data to the Visualforce email template as an attachment and you write anonymous APEX code schedule field-update of the custom object... For SFDC developers, this is almost a daily task... trying to put about five different technologies together to do tasks that seem so simple.... And this can cause management headaches and tensions too - Typically, you'd find this out after getting a suggestion to do something that doesn't work in the user-community (like someone already said), and then trying many things that, after you developed them you'd find they just don't work for some odd-ball reason - like "you can't schedule a VisualForce page", or "you can't call getContent from a schedulable context" or some other arcane reason.

There are so many, many maddening little gotcha's on the SFDC platform, that once you know WHY they're there, it makes sense... but they're still very bad limitations that keep you from doing what you need to do. Here's some of mine;

1. You can't get record owner information "out of the box" on pretty much any kind of record - you have to write a trigger that links the owner on create of the record to the record you're inserting. Why? Short answer because an owner can be either a "person" or a "queue", and the two are drastically different entities... Makes sense, but it can turn a project literally upside down.

2. Maddening security model. Example: "Manage Public Reports" permission is vastly different from "Create and Customize Reports" and that basically goes for everything on the platform... especially folders of any kind.

3. As mentioned, support is basically non-existent. If you are an extremely self-sufficient individual, or have a lot of SFDC resources, or have a lot of time and/or a very forgiving manager, or are in charge of a SFDC system that's working fine, you're in pretty good shape. If you are not in any of these positions, you can find yourself in deep trouble.

SFDC is a very seductive business proposition... no equipment footprint, pretty good security, fixed price, no infrastructure, AND you get web-based CRM with batchable, and schedualble processing... But as the other posters said, it is really quite a ramp-up in development learning, and if you go with consulting, I think the lowest price I've seen was $200/hour.

Salesforce tends integrate with other things years after some technologies become common-place - JSON and jquery come to mind... and if you have other common infrastructures that you want to do an integration with, like JIRA, expect to pay a lot extra, and they can be quite buggy.

And as one of the other posters mentioned, you are constantly fighting governor limits that can just drive you nuts... an attachment can NOT be > 5MB. Period. And sometimes < 3MB (if base64 encoded). Ten HTTP callouts in a class. Period. There are dozens of published governor limits, and many that are not which you will undoubtedly find and just want to run out of your office screaming.

I really, REALLY like the platform, but trust me - it can be one really cruel mistress.

But in fairness to SFDC, I'd say this: the biggest problem I find with the platform is not the platform itself, but the gargantuan expectations that almost anyone who sees the platform, but hasn't developed on it has.... and those people tend to be in positions of great authority in business organizations; marketing, sales, management, etc. Huge disconnects occur and heads roll, or are threatened to roll daily - all because there's this great platform out there with weird gotchas and thousands of people struggling daily to get their heads around why things should just work when they just don't and won't.

EDIT:
Just to add to lomaxx's comments about the MVC; In SFDC terminology, this is closely related to what's known as the "viewstate" -- aand it can be really buggy, in that what is on the VF page is not what is in the controller-class for the page. So, you have to go throught weird gyrations to synch whats on the page with what the controller is going to write to SF when you click your "save" button (or make your HTTP callout or whatever).... man, it's annoying.

---

I think other people have covered the disadvantages in more depth but to me, it doesn't seem to use the MVC paradigm or support much in the way of code reuse at all. To do anything beyond simple applications is an exercise in frustration compared to developing an application using something like ASP.Net MVC.

Furthermore, the tools, the data layer and the frustration of trying to refactor code or rename fields during the development process doesn't help.

I think as a CMS it's pretty cool but as a platform for non CMS applications, it's doesn't make sense to me.

---

The security model is also very very restrictive... but this isn't the worst part. You can't currently assert whether a user has the ability to perform a particular action.

You can check to see what their role is, but you can't check if that role has permissions to perform the current action.

Even worse is the response from tech support to "try the action and if there's an exception, catch it"

---

Considering Force.com is a "cloud" platform, its ability to act as a client to an external WSDL-defined service is pretty underwhelming. See http://force201.wordpress.com/2010/05/20/when-generate-from-wsdl-fails-hand-coding-web-service-calls/ for what you might end up having to do.

---

To all above, I am curious how the release of VMforce, allowing Java programmer to write code for Force.com, changes the disadvantages above?

http://www.zdnet.com/blog/saas/vmforcecom-redefines-the-paas-landscape/1071

---

I guess they are trying to address these issues. At dreamforce they mentioned they we're trying to drop the Governor limits to only 4. I'm not sure what the details are. They have a REST API for early access, and they bought heroku which is a ruby development in the cloud. They split out the database, with database.com so you can do all your web development on and your db calls using database.com.

I guess they are trying to make it as agnostic as possible. But right about now these are all announcements and early access so like their Safe Harbor statements don't purchase on what they say, only on what they currently have.

참고URL : https://stackoverflow.com/questions/1664503/disadvantages-of-the-force-com-platform