1

私はすでに多くのビジネス サービスを実装しており、それらを WCF によってサービスとして公開しています。

各サービスに 1 つのエンドポイントを持つという考えは好きではありません.....私のリポジトリが成長するにつれて、将来的に維持することが問題になる可能性があります....

以下のコードが適切なアプローチであり、このソリューションを進めることができるかどうか、wcf の専門家の意見を知りたいです。

ビジネス サービス A:

[ServiceContract]
public interface IServiceA
{
    [OperationContract]
    object AddA(object a);
    [OperationContract]
    object Update();
}

ビジネス サービス B:

[ServiceContract]
public interface IServiceB
{
    [OperationContract]
    object AddB(object b);
    [OperationContract]
    object Update();
}

サービスAの具体的な実装

public class ConcreteServiceA : IServiceA
{
    public object AddA(object a)
    {
        Console.WriteLine("ConcreateServiceA::AddA");
        return null;
    }

    public object Update()
    {
        Console.WriteLine("ConcreateServiceA::Update");
        return null;
    }
}

サービス B の具体的な実装

public class ConcreteServiceB : IServiceB
{
    public object AddB(object b)
    {
        Console.WriteLine("ConcreateServiceB::AddB");
        return null;
    }

    public object Update()
    {
        Console.WriteLine("ConcreateServiceB::Update");
        return null;
    }
}

私の単一のサービスは、各サービスへの関心を分離するために部分的です。そのコンストラクターは上記の両方のビジネス サービスに依存し、IoC を使用して注入されることに注意してください。

コンストラクターの一部

public partial class WCFService
{
    IServiceA _a;
    IServiceB _b;
    public WCFService()
        : this(new ConcreteServiceA(), new ConcreteServiceB())
    {

    }
    public WCFService(IServiceA serviceA, IServiceB serviceB)
    {
        _a = serviceA;
        _b = serviceB;
    }
}

IServiveA のみを実装する部分クラス

public partial class WCFService : IServiceA
{
    object IServiceB.AddB(object b)
    {
        return _b.AddB(b);
    }

    object IServiceB.Update()
    {
        return _b.Update();
    }

}

IServiceB のみを実装する部分クラス

public partial class WCFService : IServiceB
{
    object IServiceA.AddA(object a)
    {
        return _a.AddA(a);
    }

    object IServiceA.Update()
    {
        return _a.Update();
    }
}

クライアント側では、次のように使用します。

        var endPoint = new EndpointAddress("http://localhost/teste");
        ChannelFactory<IServiceA> _factoryA = new ChannelFactory<IServiceA>(new BasicHttpBinding(), endPoint);
        IServiceA serviceA = _factoryA.CreateChannel();
        serviceA.Update();

        var netTcpEndPoint = new EndpointAddress("net.tcp://localhost:9000/teste");
        ChannelFactory<IServiceB> _factoryB = new ChannelFactory<IServiceB>(new NetTcpBinding(), netTcpEndPoint);
        IServiceB serviceB = _factoryB.CreateChannel();
        serviceB.Update();

ご意見やその他の提案をいただければ幸いです。

4

1 に答える 1

0

複数のエンドポイントに問題はありません。これはプロセスの一部です。ただし、間違っているのは、複数のエンドポイントで機能を複製することです。「UpdateThis」または「AddThat」の開発者は何人必要ですか? これは制御不能になり、メンテナンスの頭痛の種になります。コンストラクターを見てください。新しいサービスを追加して 1 つのサービスに統合するにつれて、コンストラクターはどんどん大きくなります。

きめの細かいものではなく、きめの粗いものと考えてください。

別の方法として、リクエスト オブジェクトをパラメータとして渡し、レスポンス オブジェクトを返すこともできます。このアプローチは、コードを合理化し、投稿で言及したメンテナンスの問題を回避するのに役立ち、提案を提供します。

したがって、次のようになります。

// Your service will return a very generic Response object
public interface IService
    {
        Response YourRequest(Request request);
    }

// Your service implementation
public partial class WCFService : IService
    {
         Response IService.YourRequest(Request request)
         {
            //inspect the Request, do your work based on the values 
            //and return a response object               
         }
    }

// Your request object
public class Request()
    {
       object YourClass{get;set;}
       DoWhat Action{get;set;} //enum, constants, string etc.
       int ID {get; set;}
    }

 // Your response object
    public class Response()
        {
          bool Success {get; set;}
        }

// Create Request object
var request = new Request(){YourClass = YourClassName , Action DoWhat.Update(), ID=1};

// Your service call
var endPoint = new EndpointAddress("http://localhost/teste");
                ChannelFactory<IService> _factory = new ChannelFactory<IService>(new BasicHttpBinding(), endPoint);
                IService service = _factory.CreateChannel();
var response = service.YourRequest(request);

これで、きめの細かいアプローチを削除し、きめの粗いアプローチに置き換えました。詳細を知りたい場合はお知らせください。

于 2012-12-04T18:59:38.637 に答える