Qual estrutura é melhor para implementar um aplicativo de forma robusta, usando a API JS do ArcGIS Server?

No fórum da Esri , o usuário Matt Moyles sugeriu que a abordagem usada nas amostras da Esri JS não é adequada para o desenvolvimento robusto de um aplicativo de mapeamento da web usando HTML, JavaScript e CSS:

A abordagem sugerida pela ESRI para o desenvolvimento de aplicativos javascript é antiga e desatualizada. Eu não recomendaria seguir as amostras. O Dojo 1.7 suporta AMD com carregamento de dependência assíncrono. Eu começaria com o modelo padrão dojo e "trabalharia" a API do Arcgis nisso. As amostras não são adequadas para desenvolvedores de aplicativos sérios. Eles são principalmente apenas provas de trechos de conceitos.

Um aplicativo sério deve ser desenvolvido com o auxílio de algum tipo de estrutura para ajudar a estruturar as coisas. Eu tenho usado dojox.mvc com grande sucesso! Mas outras opções incluem coisas como backbone.js, spine.js ou até MVC javascript.

Dojo Boilerplate - https://github.com/csnover/dojo-boilerplate

• alguém concorda / discorda desta afirmação?
• existem exemplos on-line de melhores abordagens para o desenvolvimento de aplicativos da web usando a API JS do ArcGIS Server?

Concordo com Moyles que as amostras são apenas amostras e o boateplate do dojo é um ótimo recurso, no entanto, no atual snovers o boilerplate não é uma solução viável. Você tem duas versões diferentes do dojo acontecendo lá. A API js atual ainda usa a sintaxe de requisição clássica do dojo 1.6.1 e não suporta AMD. Tenho certeza de que um js api mais recente será construído no 1.7.xe desde que converter módulos clássicos dojo.defined em AMD é basicamente trivial, eu escolheria essa rota.

Se você está iniciando seu projeto agora , eu escolheria qualquer estrutura do lado do servidor que você desejasse usar (se for necessário para o seu aplicativo. Se for apenas um visualizador de página sem requisitos do lado do servidor, isso não complicará demais). Pode ser trilhos, php, asp, o que for. Siga as melhores práticas para sua estrutura / idioma.

Então, como o esri é construído no dojo, você já está carregando uma excelente estrutura js para criar aplicativos da web em grande escala. Estruture seu código para que o carregador do dojo possa carregar seus widgets e módulos com o dojo requer sintaxe. Escreva widgets e módulos do dojo, use ferramentas dijits e dojox quando necessário ( http://dojotoolkit.org/documentation/tutorials/1.6/declare , http://dojotoolkit.org/documentation/tutorials/1.6/recipes/custom_widget/ , http : //dojotoolkit.org/documentation/tutorials/1.6/understanding_widget , http://dojotoolkit.org/documentation/tutorials/1.6/templated , http://dojotoolkit.org/documentation/tutorials/1.6/cdn ). Não escreva js embutido como as amostras. Criar umaCrie um perfil para otimizar todo o seu código na hora da produção.

Você precisa manter seu código esri e personalizado separados até certo ponto, porque eles não oferecem a fonte para compilação - ele já foi criado e minificado. A ferramenta de construção não gosta muito disso.

EDITAR

Eu criei uma ferramenta grunt, esri_slurp para baixar a esri js api para que você possa usá-la como um pacote em seus aplicativos. Isso permite que você execute a compilação e obtenha um único arquivo.

Deveria ser bastante óbvio que as amostras não devem ser aplicações sérias: são amostras.

Dito isto, é muito menos comum, no mundo típico da Internet, usar algo como Backbone do que usar dojo, que é conhecido por ser expansivo e complexo, mas geralmente desnecessário.

Se você pudesse descrever mais seu objetivo, seria mais fácil fazer uma recomendação sólida. Coisas como Backbone são escritas para aplicativos completos do lado do cliente - portanto, se você está realmente fazendo a maior parte do seu trabalho em PHP, ASP ou nodejs, é menos necessário. Ou, se você não precisar de várias páginas e exibições conectadas, poderá facilmente conviver com apenas jQuery, ou nenhuma estrutura.

Concordo plenamente. ESRI é uma API javascript, sinto que eles estão competindo com o ArcGIS Viewer for Flex. As amostras nada mais são do que apenas uma prova de conceito de como você pode usar seus dijits ... Desejo que eles forneçam uma API javascript pura simples e permitam que o usuário decida qual estrutura as pessoas usarão como Bing, Google, Openlayers e várias outras. ..

O jsRevolution, a nova estrutura JavaScript e ferramenta de construção do OmniStation, é a estrutura comercial mais robusta disponível no mercado. Ele foi projetado para implantações em larga escala de aplicativos não triviais. Eu represento o OmniStation. Nossos clientes podem ter 100 ou 1000 de classes, 10 e até 100 de desenvolvedores. Embora esses clientes considerem a estrutura indisponível, o jsRevolution é prático para determinadas aplicações com apenas 25 classes.

Os muitos recursos do jsRevolution incluem: carregamento assíncrono, namespacing sem código, exibição de código comutável de URL (do Dev ao Deploy), herança sem código com validação em tempo de compilação, interface sem código com validação em tempo de carregamento, Abstraction sem código (às vezes chamado de Mixin), a capacidade para identificar um recurso como uma classe de instância, Multi-Versioning (várias versões de classes no mesmo aplicativo - simples de executar) e muitos outros recursos.