WCF行为配置为.net Remoting
本文关键字：Remoting net 配置 WCF | 更新日期: 2023-09-27 18:18:04
The Goal
运行包含业务逻辑的本地服务器(WCF)，该业务逻辑在计算机上电时跟踪信息(当用户作为普通进程登录时运行)。包含表示逻辑的本地客户机(WPF)可以连接到可用的本地服务器，以便向最终用户显示跟踪的信息。一切都是本地的和非关键的，安全不是问题。
实施最初，我基于Remoting技术(被认为是遗留技术)编写了一个本地服务器，并将本地客户端连接到本地服务器。每个共享对象都是远程共享的，并且可以被调用。
不可能远程序列化Lambda表达式(启用折射器的属性名绑定)和事件。我知道可以使用启用远程的对象绑定事件并在服务器上调用该对象，但是这会破坏WPF数据绑定。事件驱动编程很重要。
我要找什么?
创建我提到的体系结构的示例，或者，一个基本示例，显示如何配置WCF，使其以与Remoting类似的方式运行。我能找到的所有在线资源，包括MSDN的文章，都是为。net 2.0编写的。自。net 2.0以来，wcf世界发生了很多变化，使用。net 4.0是必须的。甚至可以链接到。net 4.0中WCF类似remoting行为的示例、教程或文章!
WCF是一项优秀的技术，但是正如其他人所评论的那样，这听起来像是您试图违反WCF的核心原则。我可能在这里错了，但听起来你想发送你的视图模型跨越远程边界?
在我看来，跨远程边界发送视图模型是错误的原因是架构上的原因。原因是我可能有多个客户端应用程序，即一个网站和一个wpf桌面应用程序。该视图模型仅与wpf应用程序相关。它在很大程度上是特定于平台的(在大多数情况下)。因为视图模型是特定于平台的，所以它们属于平台，而不属于你的服务。你的DTO实体(即服务模型类)必须与你的视图模型分开，因为你的视图需求可能会在任何一个客户端应用程序上改变，而你的服务可能想要提供与以前相同的服务。您的客户端应用程序依赖于您的模型实体是可以的。我通常把它们放在一个公共项目中，这个项目与我的服务项目和客户端应用程序项目一样。
是这样的。一个好的设计应该允许任何人潜在地消费它，并用它做他们想做的事情。像flickr、facebook或amazon这样的网络服务不会告诉你如何或建议你应该在你的应用程序上显示什么信息，你的应用程序也不应该这样。(我不提倡盲目地遵循他们的设计，但这是一个社区的例子，你可以看看)。
通过实现INotifyPropertyChanged接口等，你的视图模型应该默认使用可绑定的数据类型，所以更新视图模型上的数据应该是一件非常容易的事情。在设计应用程序时，最好的做法是思考，如果我做了一些不在我的功能列表中的事情，我该怎么做。我是不是把我的服务暴露给公众(尽管这不是我的本意)变得更难说了?这将使您的设计保持健壮，并且在客户改变主意时保持良好状态。