Empêche la WCF d'exposer toute ma classe?

Question

Je viens de commencer à apprendre WCF, et je viens d'un arrière-plan total non-web.

J'ai construit une application de bureau à 3 niveaux, qui compile en un exe, qui s'exécute localement.

Maintenant, je veux déplacer toute la couche logique métier vers un serveur centrique, et faire de l'interface graphique une application cliente. Pour autant que je comprenne, WCF devrait être ma solution, car en effet, il m'a aidé à réaliser ce que je voulais.

Je mange pour exécuter des fonctions à distance, ce qui est la base de ce dont j'ai besoin.

Mon problème maintenant, c'est que je ne comprends pas très bien l'architecture .

Par exemple, l'un de mes services renvoie un type de données (classe) à partir de ma couche Business Logics.

Cette classe devient automatiquement disponible pour le client via le mécanisme WCF.

Mais le problème est que cette classe contient des méthodes que je ne veux absolument pas exposer au client.

Par exemple, une méthode Save (sauvegarde dans la base de données). De plus, parfois je ne veux même pas permettre au client de changer toutes les propriétés de la classe, puisque cette classe pourrait être envoyée à l'un de mes services.

Je ne souhaite pas valider de nouveau l'instance de classe dans le service.

Que dois-je faire? Dois-je construire une autre couche, une version restreinte de la logique métier, que j'expose au client? Ou est-il possible d'exposer seulement une partie de ma classe au client, sans restreindre le serveur lui-même?

Je sais que c'est une question fondamentale, mais honnêtement, j'ai beaucoup cherché avant de demander ici. Mon problème est que je ne sais pas trop quoi chercher.

Ma deuxième question est alors, avez-vous des recommandations pour toute ressource qui peut m'expliquer cette architecture ...?

Answer 1

Généralement, si vous souhaitez encapsuler votre couche de gestion, vous ne souhaitez pas exposer directement les objets métier. En effet, vous disposez désormais d'un client découplé et vous ne souhaitez pas nécessairement mettre à jour le client chaque fois que la logique métier/les propriétés changent.

C'est où Data Transfer Objects (DTO) entrent en jeu bien. Habituellement, vous voulez avoir le contrôle sur votre contrat (données et méthodes) que vous exposez. Par conséquent, vous devez explicitement créer d'autres objets (DTO) qui constituent la couche de transfert.Ensuite, vous pouvez modifier votre code client et serveur de façon autonome (tant que les deux remplissent toujours les objets du contrat).

Cela nécessite généralement un peu plus de correspondance (avant d'envoyer ou de recevoir de chaque côté), mais cela en vaut souvent la peine.

Pour WCF, vos interfaces et classes sont marquées avec [ServiceContract] et vos classes marquées avec [DataContract] constituent généralement cette couche de transfert.

Answer 2

Dans WCF pour exposer la méthode au client, vous devez la marquer avec OperationContractAttribute. Donc, si vous ne voulez pas que les clients utilisent votre méthode Save, ne les marquez pas avec cet attribut.

Plus d'infos ici: http://msdn.microsoft.com/en-us/library/system.servicemodel.servicecontractattribute.aspx

Quasiment même chose avec des propriétés, mais différents attributs: DataMemberAttribute. Si vous ne voulez pas voir le client, ne le marquez pas (DataMember attribute)

Answer 3

Mais le problème est que cette classe contient des méthodes que je ne veux absolument pas exposer au client. Pouvez-vous fournir un exemple de code de classe et d'interface? Si oui, je suis sûr que vous pourriez être en mesure d'obtenir des réponses plus précises.

Par exemple, une méthode Save (enregistre dans la base de données).

Une approche possible serait de séparer votre classe en 2 classes. Définissez les propriétés dans la première classe, puis utilisez cette classe comme classe de base de votre deuxième classe. Ensuite, utilisez la seconde classe pour définir les méthodes. Cela vous permettrait de renvoyer uniquement les propriétés tout en vous permettant de garder votre code SEC. De plus, parfois, je ne veux même pas permettre au client de changer toutes les propriétés de la classe, puisque cette classe pourrait être envoyée à l'un de mes services. Je ne souhaite pas valider de nouveau l'instance de classe dans le service.

Pendant que vous êtes en mesure de définir la logique dans la méthodes get et set pour chaque propriété, je recommande fortement revalidation toute entrée reçus entre les services simplement parce que toute modification ou erreurs futures dans un service pourrait potentiellement conduire à des problèmes plus importants au sein de votre application. En outre, cela permet également de s'assurer que votre application est plus sécurisée contre toute attaque potentielle. Dois-je créer une autre couche, version restreinte de Business Logics, que j'expose au client? Ou est-il possible d'exposer seulement une partie de ma classe au client, sans restreindre le serveur lui-même? Je suis d'accord avec les réponses ci-dessus que vous devriez être en mesure de limiter l'accès aux différentes propriétés et méthodes en utilisant les données et les attributs de méthode au sein de vos interfaces.

Ma deuxième question est alors, avez-vous des recommandations pour toute ressource qui peut m'expliquer cette architecture ...?

Si vous êtes à la recherche de formation vidéo bon marché, mais très précieux que j'ai trouvé les cours qui Pluralsight offre tout à fait bon pour l'architecture ainsi que des services WFC (BTW, je ne suis pas associé avec eux, juste apprécié leur formation).