2009-07-31 15 views
2

Nous développons une très grande application Web en .Net 3.5. Deux fournisseurs distincts sont impliqués ayant une expertise dans différents domaines. Les deux fournisseurs sont situés à distance et travaillent sur une zone fonctionnelle distincte de la même application Web. Je me demandais quelle est la meilleure façon de gérer le développement de l'interface utilisateur.Bonne façon de développer une grande application

L'interface utilisateur possède une structure maîtresse dans laquelle le côté gauche et le côté supérieur ont des liens de navigation. En cliquant sur un lien ouvre une page dans la zone principale. Les pages individuelles seront développées par chaque fournisseur. Le maître entier peut être développé par un fournisseur. Dans la maquette principale, j'utilise des iframes pour afficher la page individuelle dans la zone principale.

Je déploie l'application principale sur un pool d'IIS-Master, une application de fournisseur A sur un pool d'IIS-A et une application de fournisseur B sur un pool d'IIS-B. Le pool d'IIS pour faire l'équilibrage de charge car le nombre d'utilisateurs est élevé.

Cette application Web est également basée sur l'accès, c'est-à-dire que l'utilisateur doit se connecter pour accéder aux pages. Je comprends que je dois implémenter la signature unique ici aussi, car différents sites sont impliqués.

Est-ce une bonne idée? Y a-t-il une alternative?


EDIT APRÈS REPONSES

J'ai aussi la même appréhension que mentionné dans vos réponses. Mais la solution à laquelle je pense n'est pas seulement parce que deux fournisseurs sont impliqués. Les deux fournisseurs sont impliqués car deux zones fonctionnelles distinctes sont présentes et les deux zones ont leur propre charge utilisateur, ce qui facilite également l'équilibrage de la charge. Je pensais créer complètement deux sites avec l'authentification unique implémentée. Mais le problème est la maintenance de la partie commune de l'interface utilisateur. La bibliothèque commune est facile car elle peut être développée par un fournisseur et distribuer la DLL à un autre fournisseur. Comment pouvons-nous faire cela pour la couche d'interface utilisateur?

Répondre

1

Il peut être difficile de travailler avec des équipes distribuées, en particulier sur des applications plus volumineuses. En fait, nous modifions parfois inutilement notre architecture simplement parce que nous pensons que cela facilitera le cycle de vie du développement. Je crois personnellement que les principes fondamentaux du logiciel, comme le contrôle de version, l'intégration continue, les révisions de code et la communication ouverte, évoluent très bien. Je suggère de considérer ce projet comme une application UNIQUE qui est codée par plusieurs équipes de développement. Confiez la responsabilité de l'intégration du code à une ou plusieurs personnes, assurez-vous que toutes les équipes sont sur la même page et ne modifiez pas votre architecture en fonction de la dynamique de votre équipe. La question que vous devez vous poser est la suivante: êtes-vous vraiment mieux de maintenir inutilement plusieurs sites et un seul système de connexion? OU suggérez-vous simplement cette approche parce que vous pensez isoler les fournisseurs et les garder concentrés sur leur (s) domaine (s) principal (x) de l'application est la bonne approche?

+0

Comme je l'ai mentionné, l'isolement est dû au fait que deux expertises fonctionnelles distinctes sont requises et il serait bon de séparer ces éléments car nous pouvons équilibrer correctement les différentes zones. Comme vous pouvez le comprendre, différentes zones auront une charge différente. –

+0

Merci de fournir les mises à jour/commentaires de clarification. Désolé si ma réponse n'a pas été utile. –

4

Ma première impression sur ce que vous avez écrit est qu'il pourrait être utile de reconsidérer l'architecture.

Avec iframes vous allez rencontrer beaucoup de problèmes, le premier est le comportement du bouton de retour du navigateur.

Une alternative possible pourrait être d'utiliser les services à distance ou Web entre l'application maître et A et B et gérer l'ensemble de l'interface utilisateur en un seul endroit. Il peut être très difficile de coordonner le développement d'une interface utilisateur cohérente avec deux fournisseurs différents.

+1

+1 Le comportement du bouton de retour est une grosse affaire. Bon vous l'avez appelé, @Skrim. –

+0

Le problème principal est la ségrégation des travaux de développement. Je comprends que la solution n'est peut-être pas parfaite, mais nous devons aussi aborder le problème du développement. Quel est le problème avec le bouton de retour? –

+0

Quel est le problème avec le bouton de retour? Vérifiez ce http://www.w3schools.com/HTML/tryit.asp?filename=tryhtml_frame_navigation et le bouton de retour fonctionne bien. –

1

Pourquoi les deux parties de développement ne peuvent-elles pas travailler sur le même projet d'interface utilisateur, tant qu'elles partagent la même instance d'une branche de contrôle de source.Lorsque les pages maîtres sont développées, ils peuvent à la fois créer des pages client contre le modèle maître sans intercepter l'autre partie?

+0

s'il vous plaît lire ma question entièrement, je sais que cela peut être fait, mais considérer d'autres paramètres aussi que j'ai mentionné dans ma question. –