Is the below implementation for implementing payment gateway is correct in app services

 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);
    }

I want to implement this interface in PaypalPaymentProcessor.cs and AuthorizeNet.cs

    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
      }
   }

// Same For AuthorizNetPaymentProcessor class. Both thi开发者_StackOverflow中文版s classes used for payment gateway. But i am confused do i put above interface and classes in App Service. Because both of this classes are not fit to be part of domain and not in domain service.

Is it ok to put them in App Service and create PaymentService class in application service from where i will call them. Can i do these?

---

Your question description is very brief but I will try to answer. Is your question where you want to put your gateway/Wrapper class that uses a payment web services, right?

If the scenario is that you have a Payment web service that you want to use in your application and to be more specific, in your application service layer. Then the approach should be to put your payment webservice gateway/wrapper in infrastructure layer (in another assembly/project) and using depencey injection for inserting the gateway in constructor. I'm not sure where PayPalExpressPaymentProcessor comes in the picture. But I guess thats the gateway class that talks to the payment service.

So you maybe have a CustomerService in your application layer that will get the IPaymentService (Gateway/wrapper) in constructor (Depency injection) and call IPaymentService.ProcessPayment(...) method. This service method is actually implemented in infrastructure layer. Then your application service CustomerService also can call domain through ICustomerRepository which is also initiated through constructor (DI).

Maybe this is not your problem scenario? Hope I was able to help you...

---

hmmm... The comments doesn't seems to work. StackOverFlow need work on their AJAX requests here....

Kamal you are correct in the statement that "Application layer talks to external services". But that phrase also mean that external systems should be able to use the same Application Service API as your presentation layer. The application service consumers can be a ASP.NET web client, A IPhone app, A business system like SAP or IFS. But I mean more that all infrastructure related dependencies should not be referenced in application service layer. Complications can be that after a while your application service layer have reference to A GemBox Excel 3rd party component, WCF, MSMQ client etc. This will reslut in replacing application layer everytime you want to switch 3rd party products, update license, upgrade to a newer version. In my opinion, too large maintainence for a easy task. You also get the benefit that you can easily unit test everything from application down to domain layer, and then mock email, wcf, msmq services.

What you should have in your application service layer is interface and implementation of your services and interfaces to infrastructure services (wrapper/Adapter/you name it) that are implemented in another assembly/project. Then you only have the wcf reference in your infra project. Do you follow me? I can post some code example if you like....