none
WCF操作客户端问题 RRS feed

  • 问题

  • 客户端需要一个处理过程对数据库的数据进行计算(访问数据库),并且将计算结果显示在客户端(如显示在窗体标签上)。我的想法是把处理过程封装为一个类放到到WCF服务端,客户端需要进行计算时从WCF的服务端取得处理过程类的代理,但是客户端生成的代理如何去访问客户端的本地资源?如操作客户端的数据库或设置客户端窗体控件的属性

    2009年7月15日 5:47

答案

  • 个人觉得暂时还不是采用WCF或Remoting的问题。先讨论一下体系结构。
    有N个客户端,而数据库又不能放在服务器端。也就是说每个客户端都有自己的数据库,有点像支持离线的体系结构。
    如果是数据库不能共享,那我感觉您现在开发的应该属于单机版的系统。这样不必用到C/S的体系。
    还有您提到“数据库放在服务端是不可行的,因为有N个客户端。”我看不出有因果关系,通常会认为有N个客户端,所以才要将数据库放在服务器端。
    除非您不希望数据共享,这N个客户之间也不用互相通讯。
    2009年7月15日 7:09
  • Hi,
       我好像在哪里看到了你的问题过。呵呵,jiruan的看法是对的。我开始也没理解你的问题,看完你们的讨论算是明白了一点。

       你这个如果是每个数据库独立的话,就不需要在使用WCF了。绕远了。反而效率不高,开发繁琐。
       你可以直接开发一个组件,这个组件包含数据计算逻辑和数据访问层,然后客户端直接使用即可。
      你以后有数据通信的应用可以考虑WCF框架来做,目前的情况没必要~
    Frank.Xu Lei--谦卑若愚,好学若饥
    专注于.NET平台下分布式应用系统开发和企业应用系统集成
    Focus on Distributed Applications Development and EAI based on .NET
    老徐的博客:http://frank_xl.cnblogs.com
    2009年7月15日 9:36
    版主

全部回复

  • 个人意见,请参考:
    个人认为应把数据库也放在服务器端,这样才需要将处理过程放在服务端,否则只要封装成一个组件单独在客户端使用即可。
    因为您的资源都没有在服务端,因此不构成客户端和服务器端的体系结构。
    如果为了解耦以及未来扩展和使用方便考虑,可以在您封装的处理过程组件上做文章,设计一个配置文档,当不需要访问服务资源时,就调用本地资源。如果需要时则调用服务端接口,而这个服务端接口需要一个新的设计和实现,这时的资源都在服务端。
    2009年7月15日 6:50
  • 个人意见,请参考:
    个人认为应把数据库也放在服务器端,这样才需要将处理过程放在服务端,否则只要封装成一个组件单独在客户端使用即可。
    因为您的资源都没有在服务端,因此不构成客户端和服务器端的体系结构。
    如果为了解耦以及未来扩展和使用方便考虑,可以在您封装的处理过程组件上做文章,设计一个配置文档,当不需要访问服务资源时,就调用本地资源。如果需要时则调用服务端接口,而这个服务端接口需要一个新的设计和实现,这时的资源都在服务端。

    数据库放在服务端是不可行的,因为有N个客户端。
    那这个问题是不是不能用WCF来解决?还是我的思路有问题?
    • 已编辑 stulas 2009年7月15日 6:55 补充
    2009年7月15日 6:53
  • 个人觉得暂时还不是采用WCF或Remoting的问题。先讨论一下体系结构。
    有N个客户端,而数据库又不能放在服务器端。也就是说每个客户端都有自己的数据库,有点像支持离线的体系结构。
    如果是数据库不能共享,那我感觉您现在开发的应该属于单机版的系统。这样不必用到C/S的体系。
    还有您提到“数据库放在服务端是不可行的,因为有N个客户端。”我看不出有因果关系,通常会认为有N个客户端,所以才要将数据库放在服务器端。
    除非您不希望数据共享,这N个客户之间也不用互相通讯。
    2009年7月15日 7:09
  • 个人觉得暂时还不是采用WCF或Remoting的问题。先讨论一下体系结构。
    有N个客户端,而数据库又不能放在服务器端。也就是说每个客户端都有自己的数据库,有点像支持离线的体系结构。
    如果是数据库不能共享,那我感觉您现在开发的应该属于单机版的系统。这样不必用到C/S的体系。
    还有您提到“数据库放在服务端是不可行的,因为有N个客户端。”我看不出有因果关系,通常会认为有N个客户端,所以才要将数据库放在服务器端。
    除非您不希望数据共享,这N个客户之间也不用互相通讯。

    是这样的,每个客户端的数据是独立的。只是每个客户端对数据的处理方式不同。
    2009年7月15日 9:17
  • Hi,
       我好像在哪里看到了你的问题过。呵呵,jiruan的看法是对的。我开始也没理解你的问题,看完你们的讨论算是明白了一点。

       你这个如果是每个数据库独立的话,就不需要在使用WCF了。绕远了。反而效率不高,开发繁琐。
       你可以直接开发一个组件,这个组件包含数据计算逻辑和数据访问层,然后客户端直接使用即可。
      你以后有数据通信的应用可以考虑WCF框架来做,目前的情况没必要~
    Frank.Xu Lei--谦卑若愚,好学若饥
    专注于.NET平台下分布式应用系统开发和企业应用系统集成
    Focus on Distributed Applications Development and EAI based on .NET
    老徐的博客:http://frank_xl.cnblogs.com
    2009年7月15日 9:36
    版主
  • 我的看法和方法与Frank.Xu Lei 相同,请参考。

    2009年7月15日 9:46
  • Hi,
       我好像在哪里看到了你的问题过。呵呵,jiruan的看法是对的。我开始也没理解你的问题,看完你们的讨论算是明白了一点。

       你这个如果是每个数据库独立的话,就不需要在使用WCF了。绕远了。反而效率不高,开发繁琐。
       你可以直接开发一个组件,这个组件包含数据计算逻辑和数据访问层,然后客户端直接使用即可。
      你以后有数据通信的应用可以考虑WCF框架来做,目前的情况没必要~
    Frank.Xu Lei--谦卑若愚,好学若饥
    专注于.NET平台下分布式应用系统开发和企业应用系统集成
    Focus on Distributed Applications Development and EAI based on .NET
    老徐的博客:http://frank_xl.cnblogs.com

    呵呵,我在博客园发过,但是除了你问了一下基本没有人回复,所以就找到这里来了。

    我之所以想把计算逻辑放到服务端是出于对逻辑的安全考虑,因为C#做的组件是可以反编译的
    此外我还考虑在逻辑变更时客户端不用主动去升级

    可能是我想得太复杂了,我需要重新整理一下我的思路。十分感谢Jiyuan和Frank.Xu Lei
    2009年7月16日 2:41
  • 呵呵,不要客气。C#确实可以反汇编,但是也有多种加密措施.以前论坛里有人讨论过,你搜索一下能查询到。
    你现在的cs架构的系统,而且是单机版本的话,升级问题无法避免啊。可以考虑把计算封装为特定的组建,每次升级至替换一个文件就可以了。不需要全部重新安装。
    Frank.Xu Lei--谦卑若愚,好学若饥
    专注于.NET平台下分布式应用系统开发和企业应用系统集成
    Focus on Distributed Applications Development and EAI based on .NET
    老徐的博客:http://frank_xl.cnblogs.com
    2009年7月16日 4:40
    版主
  • 哈,楼主客气,C#能被反汇编的确是个隐患,等您有了好的加密措施,别忘了整理一份拿出来分享。:)
    2009年7月16日 5:23