我正在使用与 CSLA.NET 类似的基于 HTTP 的自定义设计开发客户端/服务器业务软件系统。我将要做的是创建客户端和服务器对象，其中客户端方法调用被序列化为 json（使用 json.net）或其他格式，然后在服务器上反序列化为镜像服务器版本。我正在使用自定义属性来标记可以远程调用的函数和类。如果它是一个实例方法，它也会序列化调用对象，而静态调用显然只会序列化方法参数。当服务器调用完成时，它将以方法结果、错误状态和实例调用的对象的新副本进行响应。
我已经有这个运行的测试版本。我现在要做的是找出用于这些客户端和服务器对象的最佳模式。我的测试版本在客户端和服务器上使用完全独立的类。虽然这很有效，但我希望它们更紧密地联系在一起，以确保所有属性都相同等。
我对 C# 比较陌生，对它们没有很多经验，但我认为也许使用接口是最好的方法。我不是选择接口与普通类继承的 100% 的原因，但我无法想到在任何情况下我都会使用基类实现，所以这似乎是一个合理的选择。我遇到的问题是当我尝试做一些事情时，比如有一个LoadCustomers方法会返回一个List<IMyObject>. 客户端版本需要将 aList<IMyObject>转换为List<MyObject_Client>. 虽然它会出错。似乎虽然它适用于转换类本身，但当你使用这样的泛型时它不起作用。我想我每次使用Listvs中的项目时都可以通过施法来获得List本身，但这对我来说似乎更混乱。我还担心在接口中定义属性，比如List<IMyObject>从技术上讲他们会接受任何类型的实现IMyObject，但实际上当我在客户端时，我只希望MyObject_Client对象在该列表中。如果我使用简单的类继承而不是接口，这两个问题似乎也会存在。
所以在这一点上，我认为最好的选择是让它成为客户端和服务器的一个对象。这意味着我将拥有一些静态上下文类来维护程序是使用客户端对象还是服务器对象。然后在每种方法中看起来像这样：
if (MyContextObject.ObjectContext == ocClient)
{
//Code to serialize and make call to server and return result
} else {
//Actual business logic
}
或者
if (MyContextObject.ObjectContext == ocClient)
{
//Call to private client version of the function
} else {
//Call to private server version of the function
}
我还考虑过可能使用在构造函数期间根据上下文设置的委托。我不确定这是否值得，因为我是一个 C# 新手。我猜它可能会提高可读性？
从所有都在一个地方的角度来看，拥有一个类会很好，并且它更容易促进客户端到服务器的调用，因为您要在服务器上使用的确切对象名称与客户端上的确切对象名称相同. 问题在于，将客户端对象与服务器对象隔离开来也有好处。
所以我的问题是我应该为这些客户端服务器对象使用什么模式？
我的担忧是：
- 鲁棒性/可靠性/速度- 这将取代一个真正的现有产品，所以我不想要缓慢或“hacky”的代码）
- 可维护性- 我希望能够轻松地进行更新并使客户端和服务器对象保持同步。编译器提供的帮助越多，以确保我没有错过任何一个对象上的某些内容越好
- 可读性——这是可维护性的一部分，但对我来说非常重要的是它简单易懂，可供多个开发人员使用。简单我的意思是对于理解我们正在使用的模式的程序员来说很容易。
- 是时候实现了——我来自一个可怕的胖客户端世界，但它的唯一好处之一是我只需要实现每种方法的一个版本。现在我有两个。实现每种方法越容易和越快越好。
- 静态- 我希望可以同时使用静态和非静态方法。像 LoadCustomers 这样的一些方法我想是静态调用。我尝试了我认为的抽象类，但当方法是静态的时遇到了问题。
- 平台- 我必须支持在从 Windows XP 开始的每个版本的 Windows 上运行客户端和服务器。我还必须能够支持任何平台（网络、桌面或移动）上的第 3 方客户端实现。我们现在提供主要的桌面应用程序来使用该软件，但我们希望能够使用我们编写的基于 html 的客户端开始与手持设备（带条形码扫描仪）进行交互。此外，今天第 3 方将直接写入我们的数据库，所以在未来我希望能够为他们提供一个安全的 API 来阻止他们破坏我们客户的数据，因为他们不知道自己在做什么：D