C# 远程处理类组织
我正在开发一个远程处理类库，以便我可以将数据库交互和业务对象保留在服务器上而不是客户端上。
我希望能够将我自己的对象返回给客户端，以便他们可以通过服务器本身与它们进行交互。
例如（半伪代码）：
服务器
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();
如何组织我的类/命名空间？我特别想知道我的系统的类引用和可扩展性。
任何形式的批评/建议都非常感激。
I'm developing a Remoting classes library so that I can keep database interaction and business object on the server and not on clients.
I'd like to be able to return my own objects to the clients so that they can interact with them through the server itself.
For example (semi-pseudocode):
Server
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);
}
}
Client
Utility utility = (Utility)getRemotingClass("Utility");
User user = Utility.getUser("admin");
string[] perms = user.getPerms();
How can I organize my classes/namespaces? I'm particularly wondering about class references and scalability of my system.
Any kind of criticism/suggestion is really appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我并不是要敲鼓，但你可能想研究一下 WCF。远程处理非常繁琐，.Net 对维护干净接口的真正支持是通过 WCF 和消息传递来完成的，而不是通过远程处理进行完整的对象状态管理。
听起来您正在做的是开发一个用于管理数据库连接的中间层。只要确保您最终不会重新开发 SQL Server 的接口即可。
I don't mean to beat a drum, but you might want to look into WCF. Remoting is very chatty and the real support for maintaining clean interfaces by .Net is being done through WCF and message passing, as opposed to full object state management through remoting.
What it sounds like you are doing is developing a middle tier for management of the database connections. Just make sure you don't end up redeveloping the interface to SQL server.
我倾向于将所有“共享”（数据传输对象）类放在一个单独的 DLL 中，服务器和客户端都引用该 DLL（如果要使用无论如何，客户端代码）。
通过将它们放在单独的程序集中，您可以加强 DTO 与用于远程传输它们的底层技术的解耦。
这意味着，如果您最终重写远程调用技术，则不必接触 DTO，只需重新使用程序集即可。
不要忘记将 DTO 标记为 [Serailizable] 属性，以便它们可以在客户端和服务器之间传输。
赫比
I tend to put all the 'shared' (Data Transfer Object) classes in a separate DLL which both the server and the client reference (you could put them in the same DLL as the server classes if you're going to distribute it with the client code anyway).
By putting them in a separate assembly, you reinforce the de-coupling of the DTOs and the underlying technology used to remotely transfer them.
This means that if you end up rewriting the remote call technology, you won't have to touch the DTOs and can just re-use the assembly.
Don't forget to mark the DTOs as with the [Serailizable] attribute so they can be transported between the client and the server.
Herbie