2010-07-22 9 views
1

Nous réexaminons notre architecture de niveau de présentation en tant que modèle pour de futurs systèmes d'entreprise réécrits (Just the presentation tier), utilisant des piles de technologies Microsoft.Architecture de présentation de présentation .NET/Blueprint pour les systèmes opérationnels

Nous avons environ 30 systèmes .NET (2, 3 et 3.5), dont environ 60% sont basés sur le Web (CWAB + Web Forms) et 40% Smart Client (utilisant CAB/SCSF, WinForms) dans une pile de SOA back-end via ASMX ou WCF (le 'back-end' architecture des systèmes est commun)

les objectifs sont

  • si possible, pour essayer de garder la base de code comme 'commun' que possible entre Web, Windows et Mobile (actuellement aucune réutilisation de MVP/MVC entre Web et WinForms)
  • Va augmenter besoin en plus pour supporter des périphériques mobiles
  • La plupart de nos systèmes sont en ligne grognement de systèmes d'affaires - fonctionnalité est plus importante que les exigences esthétiques
  • certainement un maigre vers se déplaçant à travers WPF
  • Même s'il n'y a pas de réutilisation de niveau de présentation, conserver une architecture cohérente (MVC/MVP/MVVM etc) entre les clients
  • Restez mainstream!

Quelques réflexions ont oscillé entre

  • ASP.NET MVC 2 + jQuery etc pour le web +? Prism/WPF pour Smart Client vs
  • Prism pour tous (Smart Client et Silverlight) vs
  • Web Parts Sharepoint (Portal architecture) vs
  • En quittant le Web/Winforms et en attendant que la poussière se déposer un peu plus;)

Comment le futur HTML5 affectera-t-il votre réflexion?

Excuses pour une telle question ouverte, mais apprécieraient vraiment les conseils et l'expérience de la communauté SO à ce sujet!

Merci d'avance!

Répondre

1

Nous sommes dans une situation similaire et avons beaucoup réfléchi à ce sujet. Pour nous, nous avons exclu Sharepoint Web Parts pour plusieurs raisons. Cela pourrait être un chemin valide pour certains, mais coûteux.

Nous utilisons MVC pour les interfaces utilisateur externes avec certains modules Silverlight pour des besoins spécifiques qui nécessitent une interaction utilisateur plus riche. Pour les interfaces utilisateur en interne, nous utilisons Silverlight/Prism/MVVM pour les nouveaux modules et, pour l'instant, hébergeons les nouveaux modules Silverlight dans le système WinForms Smart Client existant à l'aide d'un contrôle de navigateur. Nous avons été en mesure de créer l'interaction nécessaire entre le code Smart Client existant et les modules Silverlight avec beaucoup de problèmes. Cela a bien fonctionné pour notre système, mais votre kilométrage peut varier. Je crois que la facilité d'intégration a été facilitée par notre cadre d'application simple que nous avons utilisé à la place du framework CAB plus général mais plus compliqué pour Smart Client.À un certain moment dans le futur, lorsque nous mettons à niveau des anciens modules de WinForm vers Silverlight, supprimez-les, car ils ne sont plus nécessaires, ou réécrivez-les pour prendre en charge des changements métier significatifs. Nous allons ensuite refaire l'application hôte, embrasser complètement l'environnement Silverlight/Prism/MVVM et abandonner tout le code WinForm. L'avantage évident de cette approche est que nous n'avons pas à refaire tout l'interface en même temps.

Jusqu'à présent, cela fonctionne bien pour nous. Bonne chance quelle que soit la route que vous choisissez.

+0

Merci beaucoup Jim - Je suppose que nous sommes encore loin d'une solution baguette magique;) D'accord avec le commentaire sur CAB - il est généralement trop pour la plupart de nos applications. Quand vous dites "... modules Silverlight avec beaucoup de problèmes" - quels sont les problèmes que vous avez rencontrés? – StuartLC

+0

Seule la difficulté était de communiquer à partir du module Silverlight dans l'application hôte WinForms via le contrôle du navigateur. Cela fonctionne, mais c'est plus de travail que j'aurais aimé. http://stackoverflow.com/questions/198360/silverlight-hosted-in-winforms –