Gestion d'un projet d'application Web avec plusieurs modes de visualisation

Question

Quelle est la pratique courante pour gérer le développement d'une application Web devant être implémentée dans plusieurs modes de visualisation, à savoir desktop et mobile/iphone?

Vaut-il mieux développer plusieurs applications pour chaque mode ou essayer de conserver tout le code dans la même application? Cela fait-il une différence si toutes les fonctionnalités de la page sont identiques (c'est-à-dire que parfois les versions mobiles ne peuvent pas "faire" ce que leurs homologues Web peuvent faire)? Quels sont certains des critères pour décider si l'application doit être divisée en plusieurs projets, pièges, etc.? Existe-t-il des modèles d'architecture spécifiques qui facilitent le travail?

Il me semble qu'à moins que l'application puisse simplement être présentée dans les différentes vues, il est préférable de créer une application distincte pour chacune d'entre elles.

Supposons que l'application est similaire à Gmail ou à Facebook (une application plus grande avec plusieurs fonctionnalités), et non un simple type de hello world ou un site Web corporatif statique. J'utilise actuellement Grails pour le développement, mais cela peut probablement s'appliquer à plusieurs frameworks.

Answer 1

Vous devez créer le serveur principal en tant que service Web. Cela signifie que toute interface utilisateur peut interagir avec le service et la logique de présentation est distincte de la logique métier.

Pour les plates-formes Microsoft, les services de données ASP.NET MVC ou ADO.NET sont de bonnes options ici pour commencer. La couche de présentation doit être séparée dans un projet différent pour s'assurer qu'elle est indépendante de la logique métier.

Mais il devrait être aussi facile de le faire sur d'autres plateformes en utilisant une approche RESTful.

Answer 2

Comme mentionné ci-dessus, la séparation des préoccupations est importante. Par la suite, la construction de couches de présentation/application séparées est une décision qui doit être prise en fonction de différents paramètres (ressources, temps, coût, évolutivité, etc.). Je suggère d'étudier les modèles de conception MVC/MVP, de séparer votre logique de présentation de votre logique métier et d'examiner comment votre application sera représentée sur chaque plate-forme et où investir votre temps et votre argent.

Answer 3

Vous ne voulez certainement pas deux applications. Essayez de séparer la logique métier et la logique du contrôleur de la vue. En fonction de la complexité de l'application, la différence peut être aussi faible qu'un fichier css supplémentaire avec un type de support «handheld» vers un service Web back-end séparé (comme indiqué ci-dessus). Au milieu est d'avoir tout votre code serveur suivant le modèle

1. Recueillir les besoins
2. Exécuter la logique métier, le stockage de la valeur à afficher quelque part
3. Figure sur quelle vue utiliser
4. Générer la vue

Cela fonctionne particulièrement bien pour les systèmes qui utilisent une vue modélisée (JSP, Rails, etc.), mais cela peut également être fait pour PHP.Un service Web d'arrière-plan est une bonne idée si vous êtes susceptible d'avoir encore plus d'affichages pour le site Web, si le frontal fonctionne bien avec les services Web, ou si les frontaux sont développés par des parties séparées.

Answer 4

1) Base de données centrale pour tout

2) Une couche logique métier central. Il peut s'agir de services Web, de javabeans, etc. Il peut y avoir une logique métier Web uniquement ou mobile uniquement. C'est bon, laissez tout en un seul endroit.

3) plusieurs couches de présentation. La couche de présentation Web appelle les services Web et les génère pour un navigateur normal. La couche de présentation mobile appelle les mêmes fonctions mais les présente optimisées pour une utilisation mobile. Si vous faites plusieurs projets, si vous corrigez un bogue ou si vous insérez une fonctionnalité, vous devrez le faire sur deux sites différents, doublant ainsi votre temps de construction et de correction d'erreurs. Alternativement, vous pouvez laisser tout ce qui se trouve «sous les couvertures» au niveau de la logique métier et laisser les gens voir différentes présentations de cette logique métier en tant que site Web ou site mobile.

Espérons que ça aide.