2009-05-14 2 views
35

저는 최근에 salesforce.com이 모리슨의 Case Study을 통해 방문한 후 온라인 CRM보다 많은 것을 발견했으며,이를 통해 회사는 업무 관리 응용 프로그램을 개발합니다. 나는 플랫폼에서 우리 자신의 Works Management 시스템을 재창조하기 위해 그것을 시험해 보았습니다.salesforce.com과 Apex는 응용 프로그램 개발 플랫폼과 어떤 차이가 있습니까?

내 배경은 Microsoft 및 .Net이며, 확실한 첫 번째 선택은 asp.net입니다. 그러나 더 나은 Synergy 프로그래밍 배경을 가진 .NET 경험이있는 관리자와 관리자 인 저는 직접 가르치고 있으며 다른 RAD 옵션 (예 : Ironspeed)을 평가하고 있습니다.

비즈니스 특성은 3-5 yrs마다 실행되는 2-5 동시 건설 유형 계약에 있으며, 각각 15-50 시스템 사용자가 필요합니다. 전통적으로 우리는 캐릭터 기반의 Works Mangement 시스템을 모든 것에 사용하고 각 계약에 맞게 조정했습니다. Salesforce 라이센스 모델은 이러한 종류의 유연성에 적합하지만 개발 유연성/학습 곡선과 모든 것을 둘러싼 모든 문제에 대해 걱정하고 있습니다. Salesforce 자체 소재/블로그가 아닌 웹에서 플랫폼에 대한 중립적 인 분석은 많지 않습니다.

"전통적인".Net과 비교하여 Salesforce에서 응용 프로그램을 개발 한 경험이있는 사람이 있습니까? 노선?

답변

2

Salesforce의 .Net 쪽에서 개발하지는 않았지만, 매우 큰 Salesforce 설치를 추가하기 위해 몇 가지를 만들었습니다.

내가 말할 수있는 것은 시스템 내의 개발 도구가 혼란스럽고 항상 (개발 시간 중) 가장 큰 병목 현상은 내가 원하는 쿼리에 대한 올바른 구문을 얻는 것이 었습니다. (주의해야 할 것은 2007 년으로 돌아갔습니다)

+0

.Net comaprison은 실제로 당신이 할 수있는 것으로 알고있는 .Net을 통해 SF와의 인터페이스가 아닌 RAD 개발 플랫폼으로서 SalesForce와 비교하여 의견을 묻는 데 초점을 두었습니다. 저는 dev 도구에 실제로 깊은 인상을 받았습니다. 브라우저에서 개발할 수있는 많은 UI가 무료로 제공되어 Apex에 대한 더 깊은 정보를 얻기 위해 Eclipse로 갈 수 있습니다. – mhollers

8

당신이 얼마나 빨리 가장자리 사건을 맞출 지 말할 수는 없지만, 제가 한 모든 다른 개발과는 다르다고 말할 수 있습니다. 실행 가능한 솔루션을 만드는 데 필요한 구현 시간과 비즈니스 스폰서가 평가할 솔루션을 신속하게 반복 할 수있는 능력은 내가 경험 한 모든 환경에서 타의 추종을 불허합니다.

Apex 코드는 플랫폼에 따라 차이가있는 Java를 기반으로합니다. 그러나 코드를 통해 수행 할 수없는 작업도 있습니다. 완전한 응용 프로그램을 만드는 데 필요한 선언적 (화면 기반) 및 코드 기반 구현을 결합하면 처음에는 머리를 감싸기가 어렵습니다.

환경의 멀티 테넌트 특성으로 인해 단일 조직에서 리소스를 독점하지 못하도록하는 '거버너 제한 사항'이 있습니다. 이렇게하면 삽입 및 업데이트 트리거와 같은 구현 옵션이 제한됩니다.

응용 프로그램을 배포하는 것은 매우 다른 경험입니다.

iTunes에서 비디오 podcast로 제공되는 개발자 교육 (Dev 501)을 확인하십시오. http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=325668840 내가 말하는 것을 정확히 볼 수 있습니다.

49

Salesforce는 가장 단순한 애플리케이션 이외에도 개발하기에 다소 고통스러운 경험입니다. 세일즈 포스는 개발하려는 것이 무엇인지에 대해 매우 구체적인 아이디어를 갖고 있으며, 애플리케이션이 그러한 경계 내에 잘 들어 가지 않으면 명확한 방향을 제시합니다.

거버너 제한은 실제로 상당히 가련합니다. 16 레벨 재귀, 1 메가 힙, 쿼리에서 반환 된 개체가 200 개를 넘지 않으며 한 번의 호출에서 20 개를 초과하지 않는 쿼리입니다. 한 번의 호출로 10 개의 웹 콜 아웃, 단일 목록의 1000 개의 항목 및 계속됩니다. 궁극적 인 결과는 한 가지 한계를 극복하기 위해 생각해내는 영리함이 다른 한 가지와 충돌한다는 것입니다.

일단 특정 크기에 도달하면 모든 제한 시간을 코딩에 소비하게됩니다. Apex라는 언어는 의미있는 상속을 실제로 지원하지 않습니다. 예를 들어 Apex의 모든 객체가 SObject에서 상속받는 것처럼 단순하고 깔끔한 작업조차도 새롭고 명백하게 임의의 제한 사항을 만나는 날이 필요합니다. 그러나 generic SObject 컬렉션을 인스턴스화 할 수 없으므로 유용한 유틸리티 라이브러리를 만드는 것이 불가능합니다. 복잡한 (심지어 단순한) 데이터베이스 조인은 불가능합니다.

세일즈 포스의 툴링 및 지원 또한 매우 약합니다. 실제 개발 프로세스에 사용하기에는 신뢰할 수없고 사용하기 어렵습니다. 도구는 복잡한 종속성 문제를 해결하는 데 엄청난 어려움을 겪고 있기 때문에 배포는 악몽입니다. ​​일반적인 개발 과정에서 만들어지는 수많은 엔터티는 프로그래밍 방식으로 배포 할 수 없습니다. 다른 작은 기능들도 언어가 대소 문자를 구별하지 않는다는 사실과 같이 유쾌하지만 IDE는 대소 문자를 구분합니다. 말할 수있는 리팩토링 도구가 없으므로 정적 유형 언어의 모든 고통을 경험할 수 있습니다. 그리고 저장/컴파일 시간이 길어 주파수가 2 분을 넘는 경우가 있습니다. 그리고 물론, 하나의 저장에 여러 개의 컴파일 오류가있는 경우 (그리고 모든 변경 사항을 다시 컴파일하지 않으려 고하므로 2 분 대기로 ...) 한 번에 하나의 오류 만 발생합니다 !

관련 메모에서 Salesforce 문서가 다소 축하하다는 사실을 알았던 것 같습니다. 공통된 오류에 대한 가장 깊은 암시적인 기술 참조 또는 주어진 API 또는 기능의 제한조차도 언급 할 수 없습니다. 그것은 모두 "여기 당신이 할 수있는 위대한 일이 있습니다"라고 언급되지 않았지만 "당신도 ___을 할 것이라고 상상할 것입니다. 그러나 당신은 틀렸을 것입니다! 문서는 진정으로 마케팅 자료와 같은 느낌입니다. 저는 18 개월 이상이 환경에서 프로그래밍을 해왔으며 API 참조와 같은 기본 사항을 찾는 데 종종 어려움을 겪습니다.

Salesforce는 유연한 환경이 아닙니다. 이것은 급속 개발 환경이 아닙니다 (적어도 다른 웹 프로그래밍 프레임 워크와 비교할 때). 튜토리얼에서 보여주는 장난감 응용 프로그램 이외의 다른 응용 프로그램을 빌드하는 것은 좋은 환경이 아닙니다. 그냥 아니라고 말해.

+10

저는 salesforce와 함께 꽤 오래 동안 일해 왔으며 귀하의 게시물에 더 동의하지 않을 수 있습니다. 우리가 자체 배포 도구를 작성하고 IDE 확장을 직접 작성하려고하는 지점에 이르렀습니다. 왜냐하면 force.com이 제공하는 것은 강력한 제품과는 거리가 멀기 때문입니다. – lomaxx

+10

계속해서이 문제를 반복적으로 제기 할 수 있기를 바랍니다.Salesforce의 "소프트웨어가 아니라 Salesforce입니다"라는 모토는 소프트웨어 개발자와 가장 기본적인 작업을 수행하는 데 과도한 시간이 걸리기 때문에 오도 된 것입니다. 되풀이 수수료를 내면 전체 시스템이 그만한 가치를 훨씬 상회하게됩니다. – Jake

+1

@Ben 이보다 더 좋은 대답은 아닐 수 있습니다! – MnZ

9

Ben의 말을 들어보십시오. 정말로. 벤의 말을 들어라. Salesforce는 절대적인 고통의 세계입니다. Salesforce에 대한 유일한 장점은 마케팅 팀입니다.

12

는 좀 오래이 문제를 알고 있지만, 그것은 또한 내가 잠시 동안 플랫폼을 개발했습니다이 질문에 Disadvantages of the Force.com platform

보는 가치가있을 거라고 나는 벤 더 동의하지 않을 수 있습니다. force.com이라는 "개발 플랫폼"에는 너무 많은 잘못이 있습니다. 개발 플랫폼이라고 부르는 것이 옳지 않다고 생각하지 않습니다.

우리는 끔찍한 기술 지원 인 끔찍한 배포 지원 인 툴링 지원으로 어려움을 겪었습니다.

내가 원하는 점은 세일즈 포스가 CRM으로 시작한 다음 그들의 제안에 "클라우드 플랫폼"을 추가하기로 결정한 점입니다. 클라우드 플랫폼은 CRM 제품을 확장하는 데 중점을두고 있으며, CRM을 확장하기를 원할 경우 force.com 환경을 통해 잘 수행 할 수 있습니다.

당신이 멋지게 할 수없는 것은 그들의 CRM을 버리고 자신 만의 맞춤식 응용 프로그램을 쉽게 만들 수있게 해줍니다. 여전히 보안 및 사용자 모델에 묶여 있지만 데이터베이스에는 여전히 표준 개체가 있으며 프로덕션 환경에 여전히 표준 페이지가 있습니다. 말하는 "파일 -> 새 프로젝트"가 없습니다.

또한 다른 사람이 "자바 기반"이라고 언급했습니다. 그렇다고해서 자바 코드를 실행할 수있는 것은 아닙니다. 그것은 그들이 자바의 일부 비트를 훔쳐서 자바처럼 보이도록 만들었지 만 실제로는 그렇지 않다는 것을 의미합니다 ... 자바 라이브러리 집합을 가져 와서 클라우드로 가져올 수 없기 때문에 정말 짜증이났습니다. JSON 구문 분석과 같은 작업을 원한다면 직접 작성해야합니다.

Ovearall, 전 전염병과 같은 force.com 플랫폼을 피할 것입니다.

5

여기에 대한 대부분의 대답은 부정적인 것으로 보입니다. 나는 플랫폼을 비난하는 것이 항상 자신의 경험이 부족한 것보다 쉽다고 말합니다.

나를위한 학습 곡선이 있었고 (자바 배경에서 오는) 좌절했습니다. 구문은 비슷했지만 패러다임은 매우 다릅니다. 수천 명의 사용자가 완벽하게 확장하고 관리하기 쉽고 보안이 뛰어나며 현재 OOP, MVC 및 기타의 기본 사항을 포함하여 거의 모든 기존 프로그래밍 아키텍처를 통합 한 응용 프로그램을 구축했습니다. 다른 많은 'Gang Of Four'디자인 패턴 중 상당수는

예제 코드 나 플랫폼에 구축 된 그랜드 응용 프로그램의 방향을 알려 주시면 기꺼이 도와 드리겠습니다.

+2

작동하는 응용 프로그램이있는 경우는 물론, 상황에 따라 Salesforce가 올바른 도구 일 수 있지만 SF에서 개발한지 10 개월 만에 다시 돌아 오면 위에서 말한 모든 것이 그대로 유지됩니다. 우리가 직면 한 문제는 사용자 규모 조정과 관련이 없지만 확장 데이터 (이 응용 프로그램에서는 사용자 수에 영향을받지 않음)와 확장 기능 및 복잡성으로 인한 것입니다. 나는 당신의 앱의 크기가 평균과 같은 것을 듣고 싶어 할 것입니다. 다행이라고 들으면 기쁘다. – Ben

3

다른 유래 스레드에서 내 대답을 참조하십시오 : 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/

1

당신은 세일즈 포스와 크고 놀라운 일을 할 수있다. 유일한 문제는 많은 사소한 시스템 및 유사 기능의 총 소유 비용 (전체 SDLC)이 dotNET 및 SQL Server와 같은 전통적인 RDBMS보다 3-10 배 더 쉽습니다 . 동일한 결과에 대해 더 많은 것을 지불해야하는 이유는 무엇입니까?

관련 문제