我应该为移动客户端/服务器对象使用什么C＃类模式

Question

我正在使用基于HTTP的自定义设计开发客户端/服务器业务软件系统，该设计与CSLA.NET类似。我将要做的是创建客户端和服务器对象，其中客户端方法调用被序列化为json（使用json.net）或其他格式，然后在服务器上反序列化为镜像服务器版本。我使用自定义属性来标记可以远程调用的函数和类。如果它是一个实例方法，它也将序列化调用对象，而静态调用显然只是序列化方法参数。当服务器调用完成时，它将在实例调用的情况下响应方法结果，错误状态和对象的新副本。

我已经有了这个运行的测试版本。我现在要做的是找出用于这些客户端和服务器对象的最佳模式。我的测试版在客户端和服务器上使用完全独立的类。虽然有效，但我希望它们能够更加紧密地结合在一起，以确保所有属性都相同等。

我对C＃比较新，并且没有很多经验，但我认为使用接口可能是最好的方法。我不是100％选择接口与普通类继承的原因，但我现在无法想到我将使用基类实现的任何情况，所以它似乎是一个合理的选择。我遇到的问题是当我尝试使用LoadCustomers方法返回List<IMyObject>时。客户端版本需要将List<IMyObject>投射到List<MyObject_Client>。但它会出错。似乎虽然它适用于自己编写类，但是当你使用这样的泛型来做它时它不起作用。我想每次我使用List vs中投射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＆＃34;代码）
• 可维护性 - 我希望能够轻松地进行更新并保留 客户端和服务器对象同步。编译器提供的帮助更多，以确保我没有错过任何一个对象上的内容更好
• 可读性 - 这是可维护性的一部分，但它非常 对我而言，重要的是简单易懂的代码 将被多个开发人员使用。对于理解我们正在使用的模式的程序员来说，简单易懂。
• 实施时间 - 我来自一个可怕的胖客户世界，但是 它唯一的好处之一就是我只需要实现一个 每种方法的版本。现在我有两个。它越容易和越快 更好地实施每种方法。
• 静态 - 我希望可以同时使用静态和非静态 静态方法。我喜欢LoadCustomers之类的一些方法 是静态电话。我尝试过抽象课程，然后参加 方法是静态的问题。
• 平台 - 我必须支持在每个服务器上运行客户端和服务器 Windows版本从Windows XP开始。我也必须能够 在任何平台上支持第三方客户端实现（web或 桌面或移动）。我们提供主要的桌面应用程序来使用 软件现在，但我们希望能够开始与之接口 使用基于html的客户端的手持设备（带条形码扫描仪）我们 写。此外，今天第三方将直接写入我们的数据库 未来我希望能够为他们提供安全的API使用 阻止他们破坏我们客户的数据，因为他们没有 知道他们在做什么：D

Answer 1

您的问题非常广泛，但根据我们交换的意见，并试图远离表达意见，我将列出两条可能的路线 - 两种提供面向服务的客户端 - 服务器解决方案的工具：

1. 用于客户端 - 服务器通信的REST样式体系结构。 REST与HTTP（及其动词）紧密耦合。信徒认为RESTfull范式是完全足够的，如果你正确设计，任何事情都是可能的:-)（基于我见过的所有热情的演讲，研讨会，博客和论坛帖子的陈述）
2. 你提到了WCF。这是一个可行的选择。与REST相比，WCF将在应用程序开发的任何级别为您提供更多选择，但增加了复杂性。

我应该补充一点，在我看来，如果您需要对应用程序的服务器端进行分层，那么您提到的CSLA和OOP设计的价值会变得更有价值。该框架可以开箱即用，或作为各种问题/解决方案对的案例研究学习工具：业务规则定义/执行，跨境方法调用，数据层设计等。我会发现它非常严格，如果CSLA或类似的风格实施强加给客户 - 特别是如果您的目标是本机移动平台，或者如您的问题所示。第三方客户端实施。