0

私は本当にこの WCF テクノロジに頭を悩ませたいと思っていますが、ここ数か月の情報詰め込みにより、クライアント/サーバー アプリケーションをどのように構築すべきかという全体的な概念が多少歪んでいるようです。

私のアプリを開発し、複数のインターフェイスを備えた Duplex WCF サービスを実装する際のベスト プラクティスに誰かが光を当てることができれば。

一般的な概要: ユーザーがサーバーに接続し、SQL データベースに連絡先を追加するアプリを開発したいと考えています。私はこれを行う多くの方法を発見しましたが、アプリをさらに開発するときが来たら、私が正しい道を進んでいることを最終的に知りたいと思います.

私が発見したいくつかのモデルは...

クライアントには独自の LINQ to SQL クラスがあり、データとの間ですべてのデータを処理します....悪い。本当に遅い。Linq Select コマンドの不十分な実装の中で、LINQ および SQL 接続のオーバーヘッド。

もう 1 つのモデルは、CRUD 操作に使用される linq to sql コマンドを実装するサービスを開発することでしたが、これはサービスに接続されている他のクライアントにライブ データ更新を提供しません。

そこで、クライアントがサービスにログインすると、コールバック チャネルがコールバック リストに追加される基本的なアプリを作成しました。クライアントがサービスに新しい連絡先をフィードすると、新しい連絡先を持つすべてのチャネル クライアントへのコールバックが呼び出され、クライアント側の関数が連絡先を適切な場所に追加します。

だから今、私はユーザーオブジェクトを実装したいと思っています.2つの他のビジネスオブジェクトはProjectとItemと言い、Itemと言いましょう...私の考えはこのようなサービスを作成することです

[Serializable]
[DataContract]
[ServiceBehavior(
   ConcurrencyMode = ConcurrencyMode.Single,
   InstanceContextMode = InstanceContextMode.PerCall)]
public class Project: IProject
       {
    [DataMember()]
    public int projectID;
          public int Insert(objSubItem _objSubItem)
    {
        // code here
               }

などと

 [ServiceContract(
    Name = "Project",
    Namespace = "",
    SessionMode = SessionMode.Required,
    CallbackContract = typeof(IProjectCallback))]
public interface IProject
{
    /// <summary>
    /// Inserting a Project record to the database
    /// </summary>
    /// <param name="_project">Project from Client</param>
    /// <return>ProjectID back to the client if -1 then fail</return>
     [OperationContract()]
     int Insert(Project _project);

    public interface IProjectCallback
{
     /// <summary>
    /// Notifies the clients that a Project has been added
    /// </summary>
    /// <param name="_project">Inserted Project</param>
    [OperationContract(IsOneWay = true)]
    void NotifyProjectInserted(Project _project);
}

明らかに、クライアントとサーバーの両方のデータレコードが編集時にのみ読み取られるようにするための他のcrud関数と関数があります。

複数のオブジェクトがある場合、それをレイアウトする最良の方法は何ですか。

私は servce.cs と Iservice.cs と IserviceCallback を作成して、クライアント チャネルの人口をネゴシエートすることを考えています.. また、サービスの部分クラスを使用して Iproject と IUser を実装し、サービス コールバックを適切に呼び出すだけでなく、オブジェクトを呼び出します。入れる。

私はこのようにしますか

 [ServiceContract(Name = "Service",
 Namespace = "", 
 SessionMode = SessionMode.Required, 
 CallbackContract = typeof(IServiceCallBack))]
 [ServiceKnownType(typeof(Project))]
 [ServiceKnownType(typeof(User))]
 public interface IService
 {

     // code here
 }

そしてまた

    [ServiceBehavior(
    ConcurrencyMode = ConcurrencyMode.Single, 
    InstanceContextMode = InstanceContextMode.PerCall)]
    public partial class Service :  IUser
    {

    public int Insert(User _User)
    {
       //       
    }
    }
    public partial class Service : IProject
    {

    public int Insert(Project _project)
    {
       // code here
    }
    }
    public partial class Service : IService
   {

    //   functions here 

    }
    }

1 つのインターフェイスの場合はアプローチが正しいように感じますが、「ベスト プラクティス」の支援が必要だと感じます。

よろしくお願いします。

クリス・リーチ

こんにちはリチャード、私はあなたの応答に感謝します。ご覧のとおり、これは私の最初の投稿であり、プログラミングに関連するフォーラムへの投稿は 3 回目です。Google 自動入力の履歴に示されているように、私はプログラミングの生活を Google に非常に近づけてきましたが、自分自身で質問を始める時が来ました。これまでのご支援に感謝します。分散クライアント/サービス アプリケーション間でデータの一貫性を最適に管理するための全体的なアプローチを理解したいと思っています。Telerik ORM と Entity Framework をソリューションとして検討し、WCF サービスを介してエンティティを公開していますが、クライアント間でデータの一貫性を実装するための理解が不足しています。私は netDualTcp チャット アプリケーションを開発し、クライアント コールバック コンテキストのリストを使用して、参加/脱退およびチャット機能を送信しました。全体像はわかりませんが、SQLデータベース内のすべてのテーブルのメモリ内(静的)バージョンがあり、可能であればクライアントをこれらのリストに直接バインドするか、カスタムユーザーに最適なようですサーバーは、特定のユーザー コントロールを開いているユーザーを認識し、コールバック コントラクトに登録されているクライアントに変更を指示できます。そうすれば、クライアントはアプリケーションを開くたびにプロジェクト全体をロードする必要がなくなります。ユーザーがアプリケーションのさまざまな部分を使用し、一度にすべての情報にアクセスする必要がない連絡先/助成金アプリケーション プログラムなどの多目的アプリケーションを考えています。ユーザーが最初にログインするとき、サービスがクライアントのコールバック コントラクトをアタッチし、基本的な状態などの認証アクションでいくつかの情報がクライアントにロードされることを期待しています。つまり、管理者の場合は、一度通知などを受け取ります。ログインすると、空白のキャンバスが表示されますが、カスタム ユーザー コントロールをドッキング パネル タイプのインターフェイスにロードし始めます。これは、クライアントへのロード/データ転送時間を最小限に抑え、両方のクライアントで CPU 処理時間を解放しながら、並行性と一貫性を最適に管理する方法について少し行き詰まっているところだと思います。プログラミングにはこれを行う方法が複数あることは知っていますが、このフォーラムの人々から、このタイプの魂への最良のアプローチが何であると感じているかを知りたいです. 私はそれが深いトピックであることを理解していますが、私はここまで来たと感じています。再度、感謝します

4

1 に答える 1

0

一般に、サービスを抽象的ではない視点から捉えることで、適切な場所にたどり着くことができます。私のサービスの消費者は何をする必要がありますか?

私は明らかに、データを作成および操作するためにビジネス層で使用される内部ドメイン オブジェクトを持っています。ただし、ビジネス層が行う方法は、サービスの機能を分割するための最良の方法であるとは限りません。

たとえば、プロジェクトに少なくとも 1 人のユーザーが必要な場合は、プロジェクトを作成するときに、同時に少なくとも 1 人のユーザーを送信する必要があります。サービス操作では、自己完結型のビジネス トランザクションを実行するために必要なすべてのデータをカプセル化する必要があります。

同様に、多くの分散システムの死の鐘はレイテンシーです。何かを完了するには、多くのラウンドトリップが必要です。たとえば、ユーザーをプロジェクトに追加できるようにする必要があります。実際には、多くのユーザーをプロジェクトとして追加したいと思うでしょう。したがって、複数回呼び出す必要がある単一のユーザーではなく、ユーザーのリストを受け入れる操作をモデル化する必要があります。

したがって、プロジェクト サービスでは、サービス コントラクトを通じて、1 つまたは複数のプロジェクトに関連するすべてのことを実行できる必要があります。ユーザーがプロジェクトから独立して生活できる場合は、ユーザー サービスも利用できます。それができない場合は、すべてをプロジェクトに集中させる必要があるため、ユーザー サービスを利用できません。

多くの場合、ビジネス トランザクションはドメイン エンティティに対する単純な CRUD 操作以上のものであり、サービスはデータ モデルを反映するのではなく、それらをモデル化する必要があります。

于 2011-06-19T10:32:22.177 に答える