Pergunta

Estamos a visitar a utilizar a plataforma Force.com como nossa plataforma de desenvolvimento e as vendas caras e no site da force.com estão cheios de razões pelas quais é a melhor plataforma do mundo. O que eu estou procurando, porém, é algumas desvantagens de se utilizar essa plataforma.

Foi útil?

Solução

Aqui estão 10 para você começar.

  1. Apex é uma linguagem proprietária. À excepção do force.com Eclipse plugin, há pouca ou nenhuma ferramentas disponíveis, tais como refatoração, análise de código, etc.
  2. Apex foi modelado em Java 5, que é considerada a ser atrasada outras línguas, e sem ferramentas (ver # 1), pode ser bastante complicado.
  3. Implantação ainda é bastante manual com muitas armadilhas e etapas manuais. Esta situação está a melhorar lentamente ao longo do tempo, mas você vai ficar desapontado se você está acostumado a ter implantações automatizadas.
  4. Apex carece de pacotes / namespaces. Todas as suas classes, as interfaces, etc. viver em uma pasta no servidor. Este código faz muito menos nomes de classe / interface necessariamente longa para conflitos de nome evitar e para fornecer contexto organizado e. Esta é uma das minhas maiores queixas, e eu não iria escolher livremente a construir sobre force.com por esta razão.
  5. O "force.com IDE", aka force.com eclipse plugin, é incrivelmente lento. Salvando qualquer arquivo, seja ele um arquivo de classe, arquivo de texto, etc., geralmente leva pelo menos 5 segundos e, por vezes, até 30 segundos, dependendo de quantos objetos, tipos de dados, arquivos de classe, etc, são em sua org. A poupança é também uma ação de bloqueio, exigindo não só a compilação, mas uma sincronização completa do seu projeto local com o servidor. Ordens de magnitude mais lento do que Java ou .NET.
  6. A comunidade de desenvolvedores on-line não parece muito saudável. Tenho notado muita posts no fórum ficar sem resposta ou não resolvido. Eu acho que isso pode ter algo a ver com o software fórum salesforce.com usos, que parece sugar muito difícil.
  7. O DSL acesso a dados no Apex deixa muito a desejar. Não é nem remotamente competitiva com os gostos de (N) Hibernate, JPA, etc.
  8. O desenvolvimento de um aplicativo em Apex / VisualForce é um exercício de engenharia limites governador. Facilmente metade do tempo do programador é gasto tentando otimizar para evitar os limites governador numerosos e outras armadilhas como limites estaduais vista Visualforce. Pode-se argumentar que, se você escrever código eficiente para começar, você não terá esse problema, o que é verdade até certo ponto. No entanto, há muitas vezes que você tem razões válidas para fazer mais de x consultas em uma sessão, ou percorrer mais de registros x, etc.
  9. O ciclo Salvar-> de compilação> executar é extremamente lento, esp. quando envolve fechando e upload de todo o pacote de recursos estático apenas para fazer algo como um teste CSS menor ou mudança javascript.
  10. Em geral, a dor de uma plataforma jovem, inexperiente, sem os benefícios de ser open source. Você não tem como validar e / ou fixar bugs na plataforma. Eles dizem para publicá-la em seu IdeaExchange. Sim, boa sorte com isso.

de Conteúdo / Divulgação das informações: Existem muitos benefícios para uma plataforma hospedada, como force.com. Force.com faz aumentar regularmente a plataforma. Há uma abundância de coisas sobre ele que eu gosto. Eu faço edifício dinheiro em force.com

Outras dicas

Eu vejo que você tenha obtido algumas respostas, mas eu gostaria de reiterar o quanto tempo é desperdiçado se locomover os diversos limites governador na plataforma. Por mais que eu como a plataforma em certos níveis, gostaria muito fortemente, altamente, enfaticamente recomendo contra ela como uma plataforma de desenvolvimento de aplicação geral. É grande como uma aplicação de CRM configurável e extensível super-se é isso que você quer. Enquanto sua comercialização é excepcional em empurrar a idéia de Force.com como uma plataforma de desenvolvimento geral, não é mesmo remotamente, mas perto.

A eficiência de ter uma plataforma estável e evitar grandes problemas de desempenho e estabilidade é facilmente perdido na tentativa de código em torno dos limites que as pessoas se referem. Há tantos limites para a plataforma, torna-se completamente enlouquecedor. Estes limites não são limites high-end você vai bater uma vez que você tem um monte de usuários, você vai bater-los quase que imediatamente.

Embora geralmente há técnicas para contorná-las, é muito difícil descobrir estratégias para evitá-los enquanto você também está tentando desenvolver a lógica de negócios de sua aplicação real.

Para lhe dar um sentido simples de como desenvolvedor un-friendly o meio ambiente é, pegue a "falta de depuração ambiente" acima referido. É pior do que isso. Você só pode ver-se a 20 dos pedidos mais recentes para o servidor nos logs de depuração. Então, como você está desenvolvendo dentro do aplicativo que você tem que criar um "New" pedido de depuração, selecione o seu nome, clique em "Save", interruptor de volta para o seu aplicativo, atualizar a página, clique em voltar para o seu guia de depuração, tentar encontrar o pedido que vai abrigar o seu log de depuração, clique em "encontrar" para procurar o texto que você está procurando. É como dez cliques para olhar para uma saída de depuração. Embora possa parecer trivial, é apenas um exemplo de como pouco de cuidado e atenção tem sido dada a experiência do desenvolvedor.

Tudo sobre a plataforma de desenvolvimento é uma reflexão tardia enxertada-on. É notável para o que é, mas um PITA total para a maior parte. Se você não sabe exatamente o que você está fazendo (como em que você está certificada e ter uma compreensão muito íntimo da Apex), ele será facilmente levá-lo para cima de 10-20x a quantidade de tempo que seria em outro ambiente que fazer algo que parece que ele iria ser ridiculamente simples, se você ainda pode ter sucesso em tudo.

Os limites do regulador são realmente tão ruim assim. Você tem uma combinação de vários limites (consultas de banco de dados, linhas retornadas "instruções de script", chamadas futuras, textos explicativos, etc.) e você tem que saber exatamente o que você está fazendo para evitar estes. Por exemplo, se você tem um campo "fórmula" calculado cumulativo sobre um objeto e você tem um gatilho em um objeto filho, ele executará os gatilhos objeto pai e contar aqueles contra os seus limites. Coisas como essa não são óbvias até que tenha passado pelo processo doloroso de tentar e falhar.

Você vai tentar uma coisa para evitar um limite, e atingiu outro em um jogo interminável de "bater um limite". No processo, você vai ter que re-arquiteto drasticamente todo o seu aplicativo e abordagem, bem como reescrever todo o código de teste. Você deve ter 75% de cobertura de código de teste para implantar em produção, que na verdade é coisa muito boa, mas combinado com todos os outros limites, é muito onerosa. Você realmente vai bater limites governador escrever seu código de teste que não surgem em cenários de usuários normais, mas que irá impedi-lo de alcançar a cobertura.

Isso é para não mencionar uma série de outras questões. Embalagem não é o que você espera. Você não pode empacotar seu aplicativo e entregá-lo aos usuários sem a intervenção do usuário significativa e configuração por parte do administrador do org. O AppExchange é uma piada total, sendo que até já começou a cobrar 5K apenas para obter seu aplicativo listado. Importando com o carregador de dados é uma porcaria, especialmente se você tiver quaisquer gatilhos. Não é possível exportar todos os seus dados em uma única etapa queinclui seus relacionamentos de maneira tal que ele pode facilmente ser re-importados para outra org em uma única etapa (por exemplo, um dev org). Você só pode atualizar uma caixa de areia uma vez por mês desde a produção, sem exceções, e você não pode incluir seus dados em uma atualização por padrão, a menos que você tenha chamado o seu executivo de contas para obter esse recurso desbloqueado. Você não pode dados em massa de exclusão em objetos personalizados. Você não pode mudar seus nomes de pacotes. Certas coisas podem tomar numerosas dias para completar depois de ter solicitado-los, como uma cópia de segurança dos dados antes de você deseja implantar um aplicativo, sem relatório de progresso ao longo do caminho e não muito senso de quando exatamente a exportação ocorreu. Dado que existem problemas sincronicidade de dados se existe relação entre os dados, existem problemas sérios de integridade de dados em que não há tal coisa como uma "transação" que podem exportar vários objetos em uma única etapa. Há provavelmente algumas ferramentas comerciais para facilitar um pouco disso, mas estes não estão ao alcance para desenvolvedores normais que não podem ter um enorme orçamento.

Tudo o resto das outras pessoas disse aqui é verdade. Ele pode levar de cinco segundos a um minuto, por vezes, para salvar um arquivo.

Eu não quero ser tão negativo porque a plataforma é muito legal em alguns aspectos, e eles estão tentando fazer as coisas em um ambiente multi-tenant que ninguém mais está fazendo. É um ambiente muito inovador e poderoso em alguns níveis (eu realmente gosto VisualForce muito), mas dar-lhe mais um ano ou dois. Eles são parceria com a VMware, talvez isso vai levar a dando aos desenvolvedores um pouco mais de um cercadinho, em vez de uma cela de prisão para trabalhar.

Aqui estão algumas coisas que eu posso dar-lhe, depois de passar um pouco de tempo de desenvolvimento na plataforma na última quinzena ou assim:

  1. Não há nenhuma API RESTful. Eles têm uma API base de sabão que você pode chamar, mas não há nenhuma maneira de fazer verdadeiros chamadas repousante

  2. Não há nenhuma maneira simples de tomar suas SObjects e convertê-los em objetos JSON.

  3. As páginas de força visuais são ok até que você quiser personalizá-los e, em seguida, é todo um mundo de dor.

  4. páginas de força visuais precisam ser obrigado a SObjects caso contrário não há nenhuma maneira de obter os campos de entrada padrão, como o datepicker ou lista de selecção para o trabalho.

  5. O plugin eclipse é ok se você quer trabalhar por si mesmo, mas se você quer trabalhar em uma grande equipe com a eclipse plug-in esqueça. Ele não lida com a sincronização de e para o servidor, ele trava e não é realmente útil em tudo.

  6. NÃO HÁ DEBUGGER! Se você deseja depurar, é literalmente depurado por declarações system.debug. Este é provavelmente o maior problema que eu encontrei

  7. Seu modelo "MVC" não é realmente MVC. É muito mais perto de ASP.NET Webforms. Suas opiniões são fortemente acoplados para não só os modelos, mas os controladores também.

  8. Como armazenar um grande número de documentos não é viável. Precisamos armazenar mais de 100 GB de de documentos e que foram citados alguma figura ridícula. Nós decidimos implementar nosso armazenamento de documentos em amazonas infraestrutura S3

  9. Mesmo tho a linguagem é java com base, não é java. Você não pode importar quaisquer pacotes ou bibliotecas externas. Além disso, as bibliotecas de base que estão disponíveis são severamente limitadas, então nós nos encontramos implementação de um monte de coisas externamente e, em seguida, expondo esses bits como serviços que são chamados por force.com

  10. Você pode chamar SABÃO externo ou serviços REST com base, mas o corpo da mensagem é limitado a 100kb de por isso é muito restritiva no que você pode chamar.

Em toda a honestidade, enquanto há benefícios potenciais para desenvolver em algo como a plataforma force.com, para mim, você não poderia usar a plataforma force.com para os verdadeiros aplicativos de nível empresarial. Na melhor das hipóteses você poderia escrever alguns aplicativos básicos estilo crud mas uma vez que você se move em nada complicado remotamente eu estaria evitando-lo como uma praga.

Wow- há muito aqui que eu nem sabia que eram limitações -., Depois de trabalhar na plataforma por alguns anos

Mas apenas para adicionar algumas outras coisas ...

A razão que você não tem um depurador de linha-a-linha é precisamente porque é uma plataforma multi-tenant. Pelo menos isso é o que SFDC diz - parece que nesta época de programação rica-thread, que não é muito de uma desculpa, mas isso é, aparentemente, a razão. Se você tem que escrever código, você tem "System.debug (String)" como o depurador - Lembro-me de ter servidor mais sofisticado ferramentas de depuração em Java 1.2 cerca de 12 anos atrás

.

Outra coisa que eu realmente odeio sobre o sistema é o controle de versão. O framework Spring não é usado para o Primavera é geralmente usado para - é realmente mais fora de uma ferramenta de configuração em SFDC ao invés de controle de versão. SFDC fornece ZERO version-control.

Você pode encontrar-se preso por dias fazendo algo que deve parecem tão ridiculamente fácil, como, por exemplo, agendar um relatório SFDC para exportar para um arquivo CSV e e-mail para uma lista de destinatários ... Bem, sobre a maneira mais fácil de fazer isso é criar um objeto personalizado com um campo personalizado, com uma regra de fluxo de trabalho e um modelo de e-mail Visualforce ... e, em seguida, para o código que você precisa escrever um componente Visualforce que transmite os dados do relatório para o modelo de e-mail Visualforce como um anexo e você escrever anônimo APEX cronograma código de campo-update do objeto personalizado ... para os desenvolvedores SFDC, isso é quase uma tarefa diária ... tentando colocar cerca de cinco tecnologias diferentes juntos para fazer tarefas que parecem tão simples .... e isso pode dores de cabeça de gestão de causa e tensões também - Normalmente, você iria descobrir isso depois de receber uma sugestão a fazer algo que não funciona no usuário na comunidade (como alguém já disse), e depois de tentar muitas coisas que, depois que você desenvolveu-los você acharia que eles simplesmente não funcionam durante tanto me odd-ball razão -. como "você não pode marcar uma página VisualForce", ou "você não pode chamar getContent de um contexto schedulable" ou alguma outra razão misteriosa

Há muitos, muitos enlouquecedora pouco pegadinha é na plataforma SFDC, que uma vez que você sabe por que eles estão lá, faz sentido ... mas eles ainda são muito ruins limitações que o impedem de fazer o que você precisa Faz. Aqui estão algumas das minhas;

  1. Você não pode obter informações do proprietário record "fora da caixa" em praticamente qualquer tipo de registro - você tem que escrever um gatilho que liga o proprietário em criar do registro para o registro que você está inserindo . Por quê? Resposta curta, porque um proprietário pode ser uma "pessoa" ou uma "fila", e os dois são radicalmente diferentes entidades ... Faz sentido, mas pode transformar um projeto literalmente de cabeça para baixo.

  2. Maddening modelo de segurança. Exemplo:. "Gerenciar relatórios públicos" permissão é muito diferente de "criar e personalizar relatórios" e que, basicamente, vale para tudo na plataforma ... especialmente pastas de qualquer tipo

  3. Como mencionado, o apoio é basicamente inexistente. Se você é um indivíduo extremamente auto-suficiente, ou tem um monte de recursos SFDC, ou tem um monte de tempo e / ou um gerente muito perdoando, ou está no comando de um sistema SFDC que está funcionando bem, você está em boa bonita forma. Se você não está em qualquer uma dessas posições, você pode encontrar-se em apuros.

SFDC é uma proposta de negócio muito sedutor ... nenhum equipamento pegada, muito boa segurança, preço fixo, sem infra-estrutura, e você começa CRM baseado na web com batchable e processamento schedualble ... Mas, como os outros cartazes disse, é realmente um ramp-up na aprendizagem de desenvolvimento, e se você ir com consultoria, acho que o menor preço que eu vi foi de US $ 200 / hora.

Salesforce tende integrar-se com outras coisas anos após algumas tecnologias tornam-se lugar-comum - JSON e jQuery vêm à mente ... e se você tiver outras infra-estruturas comuns que você quer fazer uma integração com, como JIRA, espere pagar umlote extra, e eles podem ser muito buggy.

E como um dos outros cartazes mencionados, você está constantemente lutando limites governador que pode simplesmente deixá-lo maluco ... um anexo não pode ser> 5 MB. Período. E às vezes <3MB (se base64 codificado). chamadas HTTP dez em uma classe. Período. Existem dezenas de limites governador publicados, e muitos que não que você vai, sem dúvida, encontrar e só quero correr para fora de seu escritório gritando são.

Eu realmente, realmente como a plataforma, mas confia em mim - ele pode ser um amante realmente cruel.

Mas na justiça para SFDC, eu diria o seguinte: o maior problema que eu encontrar com a plataforma não é a própria plataforma, mas as expectativas gigantescas que quase qualquer um que vê a plataforma, mas não se desenvolveu no que ele tem. ... e essas pessoas tendem a estar em posições de grande autoridade em organizações empresariais; marketing, vendas, gestão, etc. desconecta enormes ocorrem e cabeças de rolo, ou estão ameaçados de rolo diária - tudo porque há esta grande plataforma lá fora, com armadilhas estranhas e milhares de pessoas que lutam diariamente para obter suas cabeças em torno porque as coisas deve apenas trabalho quando eles simplesmente não fazer e não vai.

EDIT:
Só para acrescentar aos comentários de lomaxx sobre o MVC; Na terminologia SFDC, isso está intimamente relacionado com o que é conhecido como o "viewstate" - aand pode ser realmente de buggy, em que o que está na página VF é não o que está no controlador de classe para a página. Então, você tem que ir throught oscilações estranhas para o que está de sincronização na página com o que o controlador vai escrever para SF quando você clicar com o botão "Save" (ou fazer o seu HTTP chamada ou qualquer outro) .... homem, é chato .

Eu acho que outras pessoas têm coberto as desvantagens em mais profundidade, mas para mim, não parece usar o paradigma MVC ou apoiar muito na forma de reutilização de código em tudo. Para fazer qualquer coisa além de aplicações simples é um exercício de frustração em relação ao desenvolvimento de um aplicativo usando algo como ASP.Net MVC.

Além disso, as ferramentas, a camada de dados e a frustração de tentar código ou renomear campos refactor durante o processo de desenvolvimento não ajuda.

Eu penso como um CMS é muito legal, mas como uma plataforma para aplicações não CMS, é que não faz sentido para mim.

O modelo de segurança também é muito restritiva ... mas isso não é a pior parte. Você não pode actualmente afirmar se um usuário tem a capacidade de executar uma determinada ação.

Você pode verificar para ver qual é seu papel, mas você não pode verificar se essa função tem permissões para executar a ação atual.

Ainda pior é a resposta do suporte técnico para "experimentar a ação e se há uma exceção, pegá-lo"

Considerando Force.com é uma plataforma de "nuvem", a sua capacidade de agir como um cliente a um serviço definido pelo WSDL externo é muito abaixo do esperado. Consulte http :. //force201.wordpress.com/2010/05/20/when-generate-from-wsdl-fails-hand-coding-web-service-calls/ para o que você pode acabar tendo que fazer

Para todos acima, eu sou curioso como a liberação de VMforce, permitindo programador Java para escrever código para Force.com, muda as desvantagens acima?

http://www.zdnet.com/ Blog / saas / vmforcecom-redefine-the-paas-paisagem / 1071

Eu acho que eles estão a tentar resolver estas questões. Na Dreamforce eles mencionaram que estamos tentando soltar os limites do regulador apenas 4. Eu não tenho certeza do que os detalhes são. Eles têm uma API REST para acesso antecipado, e eles compraram heroku que é um desenvolvimento ruby ??na nuvem. Eles dividir o banco de dados, com database.com para que você pode fazer todo o desenvolvimento de seu web sobre e seu db chamadas usando database.com.

Eu acho que eles estão tentando torná-lo tão agnóstico possível. Mas agora mesmo estes são todos os anúncios e acesso antecipado assim como suas declarações Safe Harbor Não compre no que eles dizem, apenas no que eles têm atualmente.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top