0

クライアントではなくサーバー上でデータベースのやり取りとビジネス オブジェクトを保持できるように、Remoting クラス ライブラリを開発しています。

サーバー自体を介してオブジェクトとやり取りできるように、独自のオブジェクトをクライアントに返すことができるようにしたいと考えています。

例（半疑似コード）：

サーバ

class Database { ... }
class Utility
{
  public User getUser(username)
  {
     return new User(username);
  }
}
class User
{
  public string[] getPerms()
  {
    return Database.query("select * from permission where user = " + this.username);
  }
}

クライアント

Utility utility = (Utility)getRemotingClass("Utility");
User user = Utility.getUser("admin");
string[] perms = user.getPerms();

クラス/名前空間を整理するにはどうすればよいですか? 特に、システムのクラス参照とスケーラビリティについて疑問に思っています。

どんな種類の批判/提案も本当に感謝しています.

4

2 に答える 2

0

私はすべての「共有」(データ転送オブジェクト) クラスを、サーバーとクライアントの両方が参照する別の DLL に入れる傾向があります (それらをサーバー クラスと同じ DLL に入れることができます。とにかくクライアントコード）。

それらを別のアセンブリに配置することで、DTO の分離と、それらをリモートで転送するために使用される基盤となるテクノロジを強化します。これは、リモート呼び出しテクノロジを書き直すことになった場合でも、DTO に手を加える必要がなく、アセンブリを再利用するだけでよいことを意味します。

クライアントとサーバー間で転送できるように、[Serailizable] 属性を使用して DTO をマークすることを忘れないでください。

ハービー

于 2010-06-25T11:16:50.480 に答える
0

太鼓を叩くつもりはありませんが、WCF について調べることをお勧めします。リモーティングは非常におしゃべりであり、.Net によるクリーンなインターフェイスを維持するための実際のサポートは、リモーティングによる完全なオブジェクト状態管理とは対照的に、WCF とメッセージ パッシングによって行われています。

あなたがしているように聞こえるのは、データベース接続を管理するための中間層を開発していることです。SQL サーバーへのインターフェイスを再開発しないようにしてください。

于 2010-06-25T10:34:18.873 に答える