2011-04-06 3 views
0
This is my interface 

    public partial interface IPaymentMethod 
    { 
     void ProcessPayment(PaymentInfo paymentInfo, Customer customer, 
     Guid orderGuid, ref ProcessPaymentResult processPaymentResult); 
     void Capture(Order order, ref ProcessPaymentResult processPaymentResult); 
     void Refund(Order order, ref CancelPaymentResult cancelPaymentResult); 
    } 

Je veux mettre en œuvre cette interface dans PaypalPaymentProcessor.cs et AuthorizeNet.csla mise en œuvre ci-dessous pour la mise en œuvre passerelle de paiement est correcte dans les services d'applications

public class PayPalExpressPaymentProcessor : IPaymentMethod 
    { 
     public void ProcessPayment(PaymentInfo paymentInfo, Customer customer, Guid orderGuid, ref ProcessPaymentResult processPaymentResult) 
     { 
     //Some code 
     } 
     void Capture(Order order, ref ProcessPaymentResult processPaymentResult) 
     { 
     // Some Code 
     } 
     void Refund(Order order, ref CancelPaymentResult cancelPaymentResult) 
     { 
     // Some Code 
     } 
    } 

// Idem pour la classe AuthorizNetPaymentProcessor. Ces deux classes sont utilisées pour la passerelle de paiement. Mais je suis confus dois-je mettre au-dessus de l'interface et des classes App Service. Parce que ces deux classes ne sont pas aptes à faire partie du domaine et pas dans le service de domaine.

Est-il acceptable de les mettre dans App Service et de créer une classe PaymentService dans le service d'application d'où je les appelle. Puis-je faire cela?

Répondre

1

Votre description de la question est très brève, mais je vais essayer de répondre. Est-ce que votre question où vous voulez mettre votre passerelle/classe Wrapper qui utilise un service de paiement web, non?

Si le scénario est que vous avez un service Web de paiement que vous souhaitez utiliser dans votre application et pour être plus précis, dans votre couche de service d'application. Ensuite, l'approche devrait consister à mettre votre passerelle/wrapper webservice de paiement dans la couche infrastructure (dans un autre assemblage/projet) et à utiliser l'injection directe pour insérer la passerelle dans le constructeur. Je ne suis pas sûr où PayPalExpressPaymentProcessor vient dans l'image. Mais je suppose que c'est la classe passerelle qui parle au service de paiement. Vous avez donc peut-être un CustomerService dans votre couche d'application qui obtiendra le IPaymentService (Gateway/wrapper) dans le constructeur (Depency injection) et appellera la méthode IPaymentService.ProcessPayment (...). Cette méthode de service est actuellement implémentée dans la couche d'infrastructure . Ensuite, votre service d'application CustomerService peut également appeler le domaine via ICustomerRepository qui est également initié par le constructeur (DI).

Peut-être que ce n'est pas votre scénario de problème? J'espère avoir été en mesure de vous aider ...

+0

PayPalExpressPaymentProcessor, cette classe parle à la passerelle paypal en appelant la fonction api de paypal avec les paramètres requis, même pour AuthorizePaymentProcessor, il parlera d'autoriser la passerelle de paiement.Mais je pensais où mettre ces classes dans l'application couche seul et créer un autre classe appelée PaymentService qui appellera fonction dans cette classe.Mais maintenant vous avez dit qu'il devrait être dans la couche INFRA. Donc, si nous voulons parler avec un système externe, alors les classes wrapper devraient être dans la couche infra et les fonctions d'appel de la couche de service App. Ai-je raison ? – kamal

+0

DO App couche ne peut contenir que des classes de service, pas les classes wrapper. Je pensais mettre des classes wrapper dans un dossier dans la couche d'application parce que j'ai lu beaucoup d'endroits que la couche d'application parle au système externe. – kamal

+0

voir ma deuxième réponse. Impossible de créer un commentaire Je ne sais pas pourquoi ... –

1

hmmm ... Les commentaires ne semble pas fonctionner. StackOverFlow besoin de travailler sur leurs demandes AJAX ici ....

Kamal vous avez raison dans la déclaration que "couche d'application parle aux services externes". Mais cette expression signifie également que les systèmes externes doivent pouvoir utiliser la même API Application Service que votre couche de présentation. Les consommateurs du service d'application peuvent être un client Web ASP.NET, une application IPhone, un système d'entreprise tel que SAP ou IFS. Mais je veux dire plus que toutes les dépendances liées à l'infrastructure ne doivent pas être référencées dans la couche de service d'application. Les complications peuvent être qu'après un certain temps votre couche de service d'application fait référence à un composant tiers GemBox Excel, WCF, client MSMQ etc. Cela se réinitialisera en remplaçant la couche d'application chaque fois que vous voulez changer de produits, mettre à jour la licence version. À mon avis, trop grande maintenance pour une tâche facile. Vous bénéficiez également de l'avantage que vous pouvez facilement tester tous les éléments, de l'application à la couche domaine, puis simulez les services email, wcf, msmq. Ce que vous devriez avoir dans votre couche de service d'application est l'interface et l'implémentation de vos services et interfaces aux services d'infrastructure (wrapper/Adapter/vous le nommez) qui sont implémentés dans un autre assembly/projet. Ensuite, vous n'avez que la référence wcf dans votre projet infra. tu me suis? Je peux poster un exemple de code si vous aimez ....