Salesforce는 가장 단순한 애플리케이션 이외에도 개발하기에 다소 고통스러운 경험입니다. 세일즈 포스는 개발하려는 것이 무엇인지에 대해 매우 구체적인 아이디어를 갖고 있으며, 애플리케이션이 그러한 경계 내에 잘 들어 가지 않으면 명확한 방향을 제시합니다.
거버너 제한은 실제로 상당히 가련합니다. 16 레벨 재귀, 1 메가 힙, 쿼리에서 반환 된 개체가 200 개를 넘지 않으며 한 번의 호출에서 20 개를 초과하지 않는 쿼리입니다. 한 번의 호출로 10 개의 웹 콜 아웃, 단일 목록의 1000 개의 항목 및 계속됩니다. 궁극적 인 결과는 한 가지 한계를 극복하기 위해 생각해내는 영리함이 다른 한 가지와 충돌한다는 것입니다.
일단 특정 크기에 도달하면 모든 제한 시간을 코딩에 소비하게됩니다. Apex라는 언어는 의미있는 상속을 실제로 지원하지 않습니다. 예를 들어 Apex의 모든 객체가 SObject
에서 상속받는 것처럼 단순하고 깔끔한 작업조차도 새롭고 명백하게 임의의 제한 사항을 만나는 날이 필요합니다. 그러나 generic SObject
컬렉션을 인스턴스화 할 수 없으므로 유용한 유틸리티 라이브러리를 만드는 것이 불가능합니다. 복잡한 (심지어 단순한) 데이터베이스 조인은 불가능합니다.
세일즈 포스의 툴링 및 지원 또한 매우 약합니다. 실제 개발 프로세스에 사용하기에는 신뢰할 수없고 사용하기 어렵습니다. 도구는 복잡한 종속성 문제를 해결하는 데 엄청난 어려움을 겪고 있기 때문에 배포는 악몽입니다. 일반적인 개발 과정에서 만들어지는 수많은 엔터티는 프로그래밍 방식으로 배포 할 수 없습니다. 다른 작은 기능들도 언어가 대소 문자를 구별하지 않는다는 사실과 같이 유쾌하지만 IDE는 대소 문자를 구분합니다. 말할 수있는 리팩토링 도구가 없으므로 정적 유형 언어의 모든 고통을 경험할 수 있습니다. 그리고 저장/컴파일 시간이 길어 주파수가 2 분을 넘는 경우가 있습니다. 그리고 물론, 하나의 저장에 여러 개의 컴파일 오류가있는 경우 (그리고 모든 변경 사항을 다시 컴파일하지 않으려 고하므로 2 분 대기로 ...) 한 번에 하나의 오류 만 발생합니다 !
관련 메모에서 Salesforce 문서가 다소 축하하다는 사실을 알았던 것 같습니다. 공통된 오류에 대한 가장 깊은 암시적인 기술 참조 또는 주어진 API 또는 기능의 제한조차도 언급 할 수 없습니다. 그것은 모두 "여기 당신이 할 수있는 위대한 일이 있습니다"라고 언급되지 않았지만 "당신도 ___을 할 것이라고 상상할 것입니다. 그러나 당신은 틀렸을 것입니다! 문서는 진정으로 마케팅 자료와 같은 느낌입니다. 저는 18 개월 이상이 환경에서 프로그래밍을 해왔으며 API 참조와 같은 기본 사항을 찾는 데 종종 어려움을 겪습니다.
Salesforce는 유연한 환경이 아닙니다. 이것은 급속 개발 환경이 아닙니다 (적어도 다른 웹 프로그래밍 프레임 워크와 비교할 때). 튜토리얼에서 보여주는 장난감 응용 프로그램 이외의 다른 응용 프로그램을 빌드하는 것은 좋은 환경이 아닙니다. 그냥 아니라고 말해.
출처
2009-12-21 21:24:28
Ben
.Net comaprison은 실제로 당신이 할 수있는 것으로 알고있는 .Net을 통해 SF와의 인터페이스가 아닌 RAD 개발 플랫폼으로서 SalesForce와 비교하여 의견을 묻는 데 초점을 두었습니다. 저는 dev 도구에 실제로 깊은 인상을 받았습니다. 브라우저에서 개발할 수있는 많은 UI가 무료로 제공되어 Apex에 대한 더 깊은 정보를 얻기 위해 Eclipse로 갈 수 있습니다. – mhollers