Domanda

Al momento stiamo cercando di utilizzare il href="http://www.salesforce.com/platform/" rel="noreferrer"> Force.com piattaforma

È stato utile?

Soluzione

Qui ci sono 10 per iniziare.

  1. Apex è un linguaggio proprietario. Altro che il force.com Plug-in Eclipse, c'è poco da nessun utensili disponibili, come il refactoring, analisi del codice, ecc.
  2. Apex è stato modellato su Java 5, che è considerato essere in ritardo rispetto altre lingue, e senza utensili (vedi # 1), può essere molto ingombrante.
  3. La distribuzione è ancora abbastanza manuale con un sacco di trucchi e passaggi manuali. Questa situazione sta lentamente migliorando nel corso del tempo, ma sarete delusi se si è abituati ad avere distribuzioni automatizzate.
  4. Apex manca pacchetti / namespace. Tutte le classi, interfacce, ecc vivono in una cartella sul server. Questo rende il codice molto meno organizzata ed i nomi di classe / interfaccia necessariamente lungo per evitare di nomi scontri e per fornire un contesto. Questo è uno dei miei più grandi lamentele, e non vorrei scegliere liberamente di costruire su force.com solo per questo motivo.
  5. Il "force.com IDE", alias force.com Plug-in Eclipse, è incredibilmente lento. Salvare qualsiasi file, sia che si tratti di un file di classe, file di testo, ecc, di solito prende almeno 5 secondi e, a volte fino a 30 secondi a seconda di quanti oggetti, i tipi di dati, file di classe, ecc, sono nel vostro org. Il risparmio è anche un'azione di blocco, che richiede non solo la compilazione, ma una sincronizzazione completa del vostro progetto locale con il server. Gli ordini di grandezza più lento di Java o .NET.
  6. La comunità di sviluppatori on-line non sembra molto sano. Ho notato un sacco di post del forum senza risposta o irrisolto. Penso che questo possa avere qualcosa a che fare con il software del forum salesforce.com utilizza, che sembra a succhiare piuttosto difficile.
  7. Il DSL accesso ai dati in Apex lascia molto a desiderare. Non è nemmeno lontanamente competitivo con artisti del calibro di (N) Hibernate, JPA, ecc.
  8. Lo sviluppo di un app su Apex / Visualforce è un esercizio di ingegneria limiti governatore. Facilmente la metà del tempo programmatore viene speso cercando di ottimizzare per evitare i numerosi limiti governatore e altri trucchi, come limiti di stato di visualizzazione Visualforce. Si potrebbe sostenere che se si scrive codice efficiente per cominciare non avrà questo problema, che è vero in una certa misura. Tuttavia ci sono molte volte che non esistono ragioni valide per rendere più di query x in una sessione o ad anello attraverso più di record x, ecc.
  9. Il ciclo di Salva-> di compilazione> run è estremamente lento, esp. quando si tratta di zippare e caricare l'intero pacchetto di risorse statiche solo per fare qualcosa di simile prova di un minore CSS o JavaScript cambiamento.
  10. In generale, il dolore di un giovane, la piattaforma alle prime armi, senza i benefici di esso essendo open source. Non hai modo di convalidare e / o correggere i bug nella piattaforma. Dicono di inviare al loro IdeaExchange. Sì, buona fortuna.

Avvertenze / Informazioni integrative: Ci sono un sacco di vantaggi per una piattaforma hosted quali force.com. Force.com fa aumentare regolarmente la piattaforma. Ci sono un sacco di cose su di esso che mi piacciono. Faccio edificio soldi su force.com

Altri suggerimenti

Vedo che hai ottenuto alcune risposte, ma vorrei ribadire quanto tempo è sprecato muoversi i vari limiti di governatore sulla piattaforma. Per quanto mi piace la piattaforma su certi livelli, sarei molto forte, altamente, con enfasi consiglio contro di essa come una piattaforma di sviluppo portata generale. E 'grande come applicazione CRM super-configurabile ed estensibile, se questo è ciò che si desidera. Mentre la loro commercializzazione è eccezionale a spingere l'idea di Force.com come piattaforma di sviluppo in generale, non è ancora nemmeno lontanamente vicino.

L'efficienza di avere una piattaforma stabile ed evitare grossi problemi di prestazioni e di stabilità è facilmente sprecati nel tentativo di codificare in giro i limiti che le persone fanno riferimento. Ci sono così tanti limiti alla piattaforma, diventa del tutto esasperante. Questi limiti non sono limiti di fascia alta ti ha colpito una volta che hai un sacco di utenti, ti ha colpito loro quasi subito.

Mentre ci sono di solito tecniche per ottenere intorno a loro, è molto difficile capire le strategie per evitare loro mentre si sta anche cercando di sviluppare la logica di business dell'applicazione effettiva.

Per darvi un semplice senso di come gli sviluppatori non-accogliente l'ambiente è, prendere la "mancanza di ambiente di debug" di cui sopra. E 'peggio di così. È possibile visualizzare solo fino a 20 dei più recenti richieste al server nei registri di debug. Quindi, come si sta sviluppando all'interno dell'applicazione è necessario creare una richiesta di debug "Nuovo", selezionare il nome, clicca su "Salva", tornare alla vostra applicazione, aggiornare la pagina, fare clic di nuovo al vostro scheda di debug, cercare di trovare la richiesta che ospiterà il vostro registro di debug, ha colpito "trovare" per cercare il testo che stai cercando. E 'come dieci clic per guardare un output di debug. Anche se può sembrare banale, è solo un esempio di quanto poco cura e considerazione è stata data l'esperienza dello sviluppatore.

Tutto ciò che riguarda la piattaforma di sviluppo è un ripensamento innestato-on. E 'notevole per quello che è, ma una valle di lacrime totale per la maggior parte. Se non si sa esattamente cosa si sta facendo (come in sei certificato e avere una conoscenza molto intima di Apex), sarà facilmente porterà verso l'alto di 10-20x la quantità di tempo che sarebbe in un altro ambiente di fare qualcosa che sembra come esso sarebbe ridicolmente semplice, se si può anche avere successo a tutti.

I limiti governatore sono davvero così male. Si avere una combinazione di vari limiti (query di database, le righe restituite, "dichiarazioni script", chiamate future, didascalie, ecc) e si deve sapere esattamente che cosa si sta facendo per evitare questi. Ad esempio, se si dispone di un rollup campo calcolato "formula" su un oggetto e si dispone di un trigger su un oggetto figlio, che eseguirà i trigger oggetto padre e contare quelli contro i propri limiti. Cose del genere non sono evidenti fino a quando hai passato attraverso il doloroso processo di cercando e non riuscendo.

Potrai provare una cosa da evitare un limite, e ha colpito l'altro in un gioco senza fine di "colpire un limite". Nel processo si dovrà ri-architetto drasticamente l'intera applicazione e l'approccio, così come riscrivere tutto il codice di prova. deve ha il 75% di copertura del codice di test per distribuire in produzione, che in realtà è molto buona cosa, ma combinato con tutti gli altri limiti, è molto gravoso. Ci troveremo a colpire limiti governatore la scrittura del codice di prova che non sarebbe venuto in normali scenari utente, ma che ti impedirà di raggiungere la copertura.

Questo è per non parlare di tutta una serie di altre questioni. Packaging non è quello che ci si aspetta. Non si può confezionare la vostra app e consegnarlo agli utenti senza l'intervento dell'utente significativo e la configurazione da parte dell'amministratore del org. AppExchange è uno scherzo totale, e hanno anche iniziato la carica 5K solo per ottenere la vostra applicazione elencato. Importazione con il caricatore di dati fa schifo, soprattutto se avete dei trigger. Non è possibile esportare tutti i dati in un unico passo checomprende le relazioni in modo tale che essa può essere facilmente re-importato in un altro org in un unico passaggio (per esempio un org dev). È possibile aggiornare solo una sandbox una volta al mese dalla produzione, senza eccezioni, e non è possibile includere i dati in un aggiornamento di default a meno che non hai chiamato il tuo account executive per ottenere quella caratteristica sbloccato. Non è possibile cancellare i dati di massa in oggetti personalizzati. Non è possibile modificare i nomi dei pacchetti. Certe cose possono prendere numerosi giorni per completare dopo averli richiesti, come ad esempio un backup dei dati prima che si desidera distribuire un app, senza relazione sui progressi compiuti lungo la strada e non ha molto senso di quando esattamente l'esportazione si è verificato. Dato che ci sono problemi di sincronicità di dati se ci sono relazioni tra i dati, ci sono seri problemi di integrità dei dati in che non esiste una cosa come una "transazione" che può esportare numerosi oggetti in un unico passaggio. Ci sono probabilmente alcuni strumenti commerciali per facilitare alcune di queste, ma questi non sono a portata di mano per gli sviluppatori normali che non possono avere un budget enorme.

Tutto il resto le altre persone hanno detto qui è vero. Si può richiedere da cinque secondi a un minuto a volte di salvare un file.

Non voglio dire di essere così negativo perché la piattaforma è molto fresco in qualche modo e stanno cercando di fare le cose in un ambiente multi-tenant che nessun altro sta facendo. E 'un ambiente molto innovativo e potente in alcuni livelli (io in realtà piace Visualforce molto), ma dare un altro anno o due. Stanno partnership con VMware, forse che porterà a dare agli sviluppatori un po 'più di un box, piuttosto che una cella di prigione per lavorare in.

Qui ci sono alcune cose che posso darvi dopo aver trascorso un bel po 'di tempo a sviluppare sulla piattaforma negli ultimi quindici giorni o giù di lì:

  1. Non c'è API RESTful. Hanno un'API basata sapone che si può chiamare, ma non c'è modo di fare vere e proprie chiamate riposanti

  2. Non c'è modo semplice per prendere le loro SObjects e convertirli in oggetti JSON.

  3. Le pagine di forza visiva sono ok fino a quando si desidera personalizzare loro e poi è tutto un mondo di dolore.

  4. visiva forza pagine devono essere vincolati a SObjects altrimenti non c'è modo per ottenere i campi di input standard come il DatePicker o selezionare Elenco di lavorare.

  5. Il plugin Eclipse è ok se si desidera lavorare da soli, ma se si desidera lavorare in una grande squadra con il plugin di Eclipse dimenticare. Essa non gestisce la sincronizzazione da e verso il server, si blocca e non è davvero utile a tutti.

  6. NON C'È DEBUGGER! Se si desidera eseguire il debug, è letteralmente il debug da dichiarazioni system.debug. Questo è probabilmente il problema più grande che ho trovato

  7. Il loro modello "MVC" non è davvero MVC. E 'molto più vicino a ASP.NET Webforms. Le vostre opinioni sono strettamente accoppiati non solo i modelli, ma i controllori così.

  8. Memorizzazione di un gran numero di documenti non è fattibile. Abbiamo bisogno di memorizzare più di 100GB di di documenti e ci avevano proposto una figura ridicola. Abbiamo deciso di implementare la nostra archiviazione dei documenti su amazzoni infrastrutture S3

  9. Comunque Anche il linguaggio è basato su Java, non è Java. Non è possibile importare tutti i pacchetti esterni o librerie. Inoltre, le librerie di base che sono disponibili sono fortemente limitate in modo che abbiamo trovato noi stessi l'attuazione di un mucchio di roba esternamente e poi esporre i bit come servizi che vengono chiamati da force.com

  10. È possibile chiamare SOAP esterno o di riposo servizi basati ma il corpo del messaggio è limitata a 100kb di quindi è molto restrittiva in quello che si può chiamare.

In tutta onestà, mentre ci sono benefici potenziali per sviluppare su qualcosa di simile piattaforma force.com, per me, non si poteva usare la piattaforma per i veri force.com applicazioni di livello enterprise. Nella migliore delle ipotesi si potrebbe scrivere alcune applicazioni di base stile CRUD ma una volta che ci si sposta in qualsiasi cosa complicato da remoto sarei evitato come la peste.

Wow c'è molto qui che non sapevo nemmeno fosse limitazioni. - Dopo che lavora sulla piattaforma per alcuni anni

Ma solo aggiungere alcune altre cose ...

La ragione per cui non si dispone di un debugger linea per linea è proprio perché si tratta di una piattaforma multi-tenant. Almeno questo è quello che dice SFDC - sembra che in questa epoca di programmazione ricchi di filo, che non è molto di una scusa, ma questo è a quanto pare il motivo. Se si deve scrivere il codice, bisogna "System.debug (String)" come debugger -. Mi ricordo di aver più sofisticati strumenti di debug del server in Java 1.2 circa 12 anni fa

Un'altra cosa che ho davvero odio circa il sistema di controllo di versione è. Il framework Spring non viene utilizzato per quello che la primavera è di solito utilizzato per - è davvero più fuori uno strumento di configurazione in SFDC piuttosto che il controllo di versione. SFDC fornisce ZERO di controllo della versione.

Si possono trovare te bloccato per giorni facendo qualcosa che dovrebbe sembrare così ridicolmente facile, come, ad esempio, la pianificazione di un rapporto SFDC per esportare in un file CSV e-mail a una lista di destinatari ... Ebbene, circa il modo più semplice per fare questo è creare un oggetto personalizzato con un campo personalizzato, con una regola di flusso e di un modello e-mail Visualforce ... e poi il codice è necessario scrivere un componente di Visualforce che i flussi i dati del report al modello di email Visualforce come allegato e si scrivere anonimo APEX programma di codice di campo-aggiornamento e l'oggetto personalizzato ... per gli sviluppatori SFDC, questo è quasi un compito quotidiano ... cercando di mettere insieme circa cinque tecnologie diverse per fare i compiti che sembrano così semplice .... e questo può causare problemi di gestione e tensioni troppo - in genere, che si può trovare questo fuori dopo aver ottenuto un suggerimento per fare qualcosa che non funziona nella user-comunità (come qualcuno ha già detto), e poi provare molte cose che, dopo averli sviluppati che si può trovare solo che non funzionano per così Mi odd-ball motivo -. del tipo "non è possibile pianificare una pagina Visualforce", o "non è possibile chiamare getContent da un contesto pianificabile" o qualche altra ragione arcana

Ci sono tante, tante piccole esasperante gotcha sulla piattaforma SFDC, che una volta che si sa perché sono lì, ha senso ... ma sono ancora molto male limiti che ti impediscono di fare quello che è necessario fare. Ecco alcuni dei miei;

  1. Non è possibile ottenere registrare le informazioni sul proprietario "out of the box" su praticamente qualsiasi tipo di disco - si deve scrivere un trigger che collega il proprietario sul creare del record al record si sta inserendo . Perché? Risposta breve perché un proprietario può essere sia una "persona" o di una "coda di", e le due sono entità radicalmente diverse ... ha un senso, ma può trasformare un progetto letteralmente a testa in giù.

  2. modello di sicurezza esasperante. Esempio:. "Gestione relazioni pubbliche" il permesso è molto diverso da "Creare e personalizzare i report" e che va praticamente per ogni cosa sulla piattaforma ... soprattutto cartelle di qualsiasi tipo

  3. Come accennato, il supporto è praticamente inesistente. Se sono un individuo estremamente autosufficienti, o di avere un sacco di risorse SFDC, o di avere un sacco di tempo e / o un manager molto indulgente, o sono a capo di un sistema di SFDC che sta lavorando bene, siete in buona forma. Se non si è in una di queste posizioni, ci si può trovare nei guai.

SFDC è molto seducente proposta di affari ... nessuna attrezzatura impronta, abbastanza buona sicurezza, prezzo fisso, nessuna infrastruttura, e si ottiene CRM web-based con batchable, e l'elaborazione schedualble ... ma come detto altri manifesti, è davvero molto una rampa-up nell'apprendimento di sviluppo, e se si va con la consulenza, credo che il prezzo più basso che ho visto è stato di $ 200 / ora.

Salesforce tende integrarsi con altre cose anni dopo alcune tecnologie diventano luogo comune - JSON e jQuery vengono in mente ... e se si dispone di altre infrastrutture comuni che si vuole fare un'integrazione con, come JIRA, si aspettano di pagare unmolto più, e possono essere molto buggy.

E come uno degli altri manifesti citato, si sono costantemente combattendo limiti governatore che può solo si guida noci ... un allegato non può essere> 5 MB. Periodo. E a volte <3 MB (se base64 codificata). Dieci didascalie HTTP in una classe. Periodo. Ci sono decine di limiti governatore pubblicati, e molti che non che si trova senza dubbio e vogliono solo correre fuori del vostro ufficio urla sono.

davvero, davvero come la piattaforma, ma credetemi - Può essere un amante davvero crudele.

Ma in tutta onestà a SFDC, direi questo: il problema più grande che ho trovato con la piattaforma non è la piattaforma stessa, ma le aspettative gigantesche che quasi chiunque che vede la piattaforma, ma non si è sviluppato su di esso ha. ... e quelle persone tendono ad essere in posizioni di grande autorità nelle organizzazioni aziendali; di marketing, di vendita, di gestione, ecc disconnette enormi si verificano e le teste rotolare, o sono minacciate a rotolare tutti i giorni - tutto perché c'è questa grande piattaforma là fuori con trucchi strani e migliaia di persone che lottano ogni giorno per ottenere le loro teste intorno perché le cose dovrebbero solo lavorare quando solo che non fanno e non sarà.

EDIT:
Giusto per aggiungere ai commenti di lomaxx sulla MVC; In SFDC terminologia, questo è strettamente legato a ciò che è noto come il "viewstate" - aand può essere davvero buggy, in quanto ciò che è sulla pagina VF è non ciò che è nel sistema di controllo di classe per la pagina. Quindi, si deve andare throught giravolte strani a synch che cosa è sulla pagina con ciò che il regolatore sta per scrivere a SF quando si fa clic con il pulsante "Salva" (o fare il vostro richiamo HTTP o altro) .... l'uomo, è fastidioso .

Credo che altre persone hanno coperto gli svantaggi in modo più approfondito, ma per me, non sembra utilizzare il paradigma MVC o sostenere molto in termini di riutilizzo del codice a tutti. Per fare qualcosa al di là di semplici applicazioni è un esercizio di frustrazione, rispetto allo sviluppo di un'applicazione che utilizza qualcosa come ASP.Net MVC.

Inoltre, gli strumenti, lo strato di dati e la frustrazione di cercare di refactoring del codice o rinominare i campi durante il processo di sviluppo non aiuta.

Credo che come un CMS è abbastanza freddo, ma come una piattaforma per applicazioni non CMS, è non ha senso per me.

Il modello di sicurezza è anche molto molto restrittiva ... ma questo non è la parte peggiore. Attualmente non è possibile affermare se un utente ha la possibilità di eseguire una determinata azione.

È possibile controllare per vedere quale sia il loro ruolo, ma non si può verificare se quel ruolo dispone di autorizzazioni per eseguire l'azione in corso.

Ancora peggio è la risposta di supporto tecnico a "provare l'azione e se c'è un'eccezione, prenderlo"

Considerando Force.com è una piattaforma di "cloud", la sua capacità di agire come un client a un servizio WSDL definito esterna è abbastanza deludente. Vedere http :. //force201.wordpress.com/2010/05/20/when-generate-from-wsdl-fails-hand-coding-web-service-calls/ per quello che si potrebbe finire per dover fare

Per tutti sopra, io sono curioso come il rilascio di VMforce, permettendo programmatore Java per scrivere codice per Force.com, cambia gli svantaggi di cui sopra?

http://www.zdnet.com/ blog / saas / vmforcecom-ridefinisce-the-PaaS-paesaggio / 1071

Credo che stanno cercando di risolvere questi problemi. A Dreamforce hanno accennato che stiamo cercando di eliminare i limiti governatore solo 4. io non sono sicuro di quello che i dettagli sono. Hanno un API REST per l'accesso precoce, e hanno comprato Heroku che è uno sviluppo rubino nella nuvola. Si dividono la base di dati, con database.com modo da poter fare tutto il vostro sviluppo web e che il db chiamate utilizzando database.com.

Credo che stanno cercando di renderlo il più possibile agnostico. Ma proprio in questi giorni questi sono tutti gli annunci e l'accesso anticipato così come le loro dichiarazioni approdo sicuro non acquistano su quello che dicono, solo su ciò che attualmente hanno.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top