Comment consommer la logique métier héritée d'une application Silverlight?

Question

J'ai un système XBap conçu comme une application à 3 couches. Le client XBap consomme la logique via un service WCF à l'aide de netTcpBinding. Pour faciliter la liaison de données et pouvoir réutiliser la validation de données intégrée à mes objets métier, j'ai choisi de référencer la bibliothèque d'objets métier depuis le client xBap au lieu de générer des proxies.

Ces objets implémentent une logique autre que la validation des données de base. La vraie logique métier est implémentée dans mon service WCF.

Maintenant, je suis confronté à un grand défi. J'ai besoin de porter le xBap à Silverlight, donc j'ai besoin de mon application Silverlight. consommer la même logique métier (qui est également utilisée par une application LOB winforms).

Certains problèmes qui se posent:

1) ne peut pas faire référence à l'entreprise bibliothèque d'objets à partir de l'application cliente silverlight parce qu'il est compilé en tant que dll régulière et non un silverlight.

2) Je ne peux pas le compiler comme une bibliothèque Silverlight parce que je perds beaucoup de fonctionnalité et de toute évidence n'est pas une bonne idée de toute façon. Si à l'avenir une nouvelle plate-forme .net se présente, je n'ai aucune garantie que la dll modifiée (silverlight) fonctionnera. J'avais un peu d'espoir quand j'ai découvert RIAServices. J'ai lu quelque part que je pourrais mettre en œuvre un service et utiliser n'importe quel type de DAL. (J'en ai une personnalisée) mais je n'ai trouvé aucun exemple montrant comment mettre RIAServices au-dessus d'une couche de gestion existante. Il vaut la peine de dire que nous n'utilisons pas (et nous ne prévoyons pas) LINQ. Chaque exemple que j'ai trouvé a commencé à utiliser RIAServices et à écrire la logique métier à partir de zéro en utilisant LINQ. RIAServices génère du code client prêt pour la connexion de données, mais je pense que je devrais changer toute la couche de gestion, ce qui coûterait très cher. Donc, la solution semble être de continuer à utiliser WCF, spécialement maintenant que silverlight 3.0 supporte une nouvelle liaison binaire, et de travailler avec des proxies au lieu des objets métier réels. Le problème est que ces proxies n'incluent pas la validation des données, la notification de changement de propriété et le suivi des modifications, trois aspects que mon entreprise effectue. RIAServices résout ces aspects et d'autres, mais il est nécessaire de travailler avec des projets Silverlight. WCF (SVCUtil.exe) génère des proxies mais ils ne sont pas 'complets' pour nos besoins. Il semble donc que je devrais développer mon propre utilitaire pour générer ces proxies en prenant un objet métier comme entrée. Avant de commencer, je voudrais savoir si quelqu'un a déjà fait face à ce problème et a été capable de le résoudre d'une manière pratique et indolore.

Merci à l'avance,

Gonzalo

Answer 1

Vérifiez ce billet de blog et de l'échantillon - Business Apps Example for Silverlight 3 RTM and .NET RIA Services July Update: Part 8: WCF Based Data Source.

Il montre l'écriture d'un DomainService utilisant les services .NET RIA qui expose les opérations et un modèle au client Silverlight, et à son tour fonctionne contre un service WCF.

Vous ne devriez pas avoir besoin de changer votre logique métier. Le DomainService en tant que couche réutilisera cela, et il serait logique que vous ne puissiez pas exposer votre logique métier/les services WCF tels quels aux clients Silverlight ...

Espérons que cela aide.