9

今日は、WCF コミュニケーションのスタイルについて質問があります。

私は時々少し拒否するので、プログラムで物事を使用し（自分で制御したい）、巨大なものは好きではありません。2 つのプログラム部分間の通信が必要な場合があり、同じマシン上やネットワーク上で通信する場合があります。

そこで、構成ファイルや svcutil などを使用する代わりに、プログラムで WCF を使用しようとしました。

以下を使用する場合：

a) 契約を定義する

[ServiceContract]
    public interface IMyContract
    {
        [OperationContract]
        bool DoSomething(string something_in);
    }

b) いくつかのコードをプログラムする

public class MySomething: IMyContract
        {
            public bool DoSomething(string something_in)
            {
                if(String.IsNullOrEmpty(something_in)
                      return false;
                return true;
            }
}

次に、プログラムでホストします

Uri baseAddress = new Uri("net.tcp://localhost:48080/MySimpleService");

            using (ServiceHost host = new ServiceHost(typeof(MyContract), baseAddress))
            {
                host.AddServiceEndpoint(typeof(IMyContract), new NetTcpBinding(), "");
                host.Open();

                Console.WriteLine("<Enter> to stop the service.");
                Console.ReadLine();

                host.Close();

後で別のプログラムからそれを消費するだけです：

var binding = new NetTcpBinding();
            var endpoint = new EndpointAddress("net.tcp://localhost:48080/MySimpleService");
            var channelFactory = new ChannelFactory<IMyContract>(binding, endpoint);

            IMyContract client = null;

            try
            {
                client = channelFactory.CreateChannel();
                bool test = client.DoSomething();
                ((ICommunicationObject)client).Close();
            }
            catch (Exception ex)
            {
                if (client != null)
                {
                    ((ICommunicationObject)client).Abort();
                }
            }

欠点は何でしょう？

分かりやすくなりませんか？

そのようなことは他の問題を引き起こす可能性がありますか？

(私は主にこれに興味があります.svcutilを使用するのは非常に面倒だと思うので、wcfサービスが独自のプログラムのcumminicationのみに使用される場合、手動で簡単に処理できるクラスの変更のためです)私は行方不明ですか？

大きな未読の XML ファイルを手動で処理するのは単にスタイルが悪いのでしょうか?

4

2 に答える 2

3

あなたの質問は複数の部分に分けることができます：

アドレスをハードコーディングしても大丈夫ですか？

いいえ。同じように、接続文字列をハードコーディングしません。また、リソースまたはサービスへのパス（少なくとも絶対パスではない）をハードコーディングしません。たとえば、サービスの新しいバージョンをテストするために、何らかの理由でいつ変更する必要があるかはわかりません。完全なエンドポイント構成を使用したくない場合は、少なくとも単純なアプリ設定を使用してください。

バインディングと構成をハードコードしても大丈夫ですか？

頻繁に変更する予定がなく、変更するたびにサーバーとクライアントを再コンパイルおよび再デプロイすることに満足している場合は、ハードコーディングできます。APIは、有効なユースケースであるため、これを提供します。

クライアントとサーバー間でサービス契約やデータ契約を共有しても大丈夫ですか？

繰り返しになりますが、アプリケーションがどのように成長するか、および展開の複雑さをどのように期待するかによって異なります。アセンブリの共有は、クライアントとサーバーの両方のコードを完全に制御できる場合に有効なユースケースですが、サーバーとクライアントアプリケーションの間に緊密な結合が生じることを覚えておく必要があります。Svcutilは、制御できない（コードがないか、.NETで記述されていない）SOAPサービスから、またはサーバーとの緩い結合を追跡するクライアント向けにクライアントを生成するのに役立つツールです。

私は非常に頻繁に共有コントラクトアセンブリを使用した構成を使用します=svcutilはありません。

編集：

とにかく、XML構成よりもコード化された構成に技術的な欠点はありません（一部の高度な構成はXMLでは使用できません）。開発者がWCFを知っていれば、XMLとコードの両方を理解できます。開発者がWCFを知らない場合は、XML構成がしばらくの間彼から隠されている可能性があるため、おそらくコードにもっと満足するでしょう。

于 2013-01-09T13:22:42.037 に答える
1

これをプログラムで行うとうまくいくはずです。主な問題は、何かを変更したい場合、またはエンド ユーザーが何かを変更する必要がある場合に発生します。エンドポイント アドレスまたはその他の構成が変更された場合、コードを再コンパイルする必要がない方がはるかに簡単です。

構成ファイルを使用すると、セットアップが別の場所に保存され、必要なときに簡単に見つけることができると思います。

ユーザーから隠したい正当な理由がある場合にのみ、構成をハードコードすることを選択します（たとえば、構成を表示したくない/混乱させたくない場合）。

于 2013-01-09T13:13:10.007 に答える