none
关于WCF服务中数据传递应该采取一个怎样的方案? RRS feed

  • 问题

  • 最近采用WCF来编写一些服务来供移动设备使用的,开始时候没有太在意,只是将其分为两部分:服务层与数据层。
    业务逻辑因为图方便就直接写在服务库中了。

    最近,别人提出请求,需要用到我这边的服务逻辑,但是由于在服务层上的逻辑带有很多验证操作,而且所有业务逻辑所用的数据对象均是和WCF的数据契约共享的。

    现在,我想将业务逻辑层单独分离出来,就是实现类似MVC的三层架构(这里的View是服务Service),使得业务逻辑(Controller)可以被其它非wcf服务库共享。

    但是,如果按照MVC的模型来做的话,这个系统内将会存在3组类似但是无关联的对象(数据契约,业务对象,实体对象),并且会有很多对象转换的操作。(我看过这篇帖子:关于WCF数据契约与实体(Model/Entity)转换(或共享)问题,里面回答是建议这样做的。)

    在这里我想再次提出一下这个问题,在WCF项目的内部,究竟采用一个怎样的数据交换模型比较合理?

    2012年12月28日 7:15

答案

  • 刚刚注意了一下您的回答里面提到了DDD,之前不曾对DDD有了解。

    刚刚临时恶补了一下,我先说说我的理解吧:

    DDD也是分为三层,跟MVC类似:Domain对应Model,Controller对应了Application,View对应了Facade;但是Application和Facade同时依赖与Domain。

    现在我项目里面WCF服务应该算是Facade的,但是之前为了方便,逻辑写在了Facade上,很多逻辑都依赖了接口上的对象。

    现在我想将Facade上的逻辑转移出来,独立到Application中,但是问题来了:以前Model层上是用NHibernate生成的表实体对象,而且和NHibernate绑定紧密,所以我不想Facade层(甚至是Application层)上依赖与这个与NHibernate紧密绑定的实体对象。

    DDD跟MVC是不一样的概念,而且不是从同一个角度来考虑问题的解决方案。鉴于此,我将不再用 DDD 的概念来给出建议,而是就事论事的来谈你的问题。

    如果你不想Facade层(甚至是Application层)上依赖与这个与NHibernate紧密绑定的实体对象,那么你就需要建立新的中间对象来同NHibernate生成的表实体对象做映射。

    • 已标记为答案 JasonMing 2013年1月5日 1:33
    2013年1月4日 9:42

全部回复

  • 你可以把实体对象实现为业务对象并标记为数据契约,这样大家都能用。这是DDD中很常用的一种模式。

    然后在服务层,当你的服务接口需要的的数据契约无法从业务层得到满足后,你再在服务层新建数据契约,并同实体对象做个转换。


    2012年12月28日 7:40
  • 感谢您的回答,这个我也曾考虑过,但是这样会导致View层同时依赖于Controller和Model。使得Model层面上某些变更会同时涉及到Controller和View。

    2013年1月4日 1:50
  • 感谢您的回答,这个我也曾考虑过,但是这样会导致View层同时依赖于Controller和Model。使得Model层面上某些变更会同时涉及到Controller和View。

    从DDD的角度讲,View 应该依赖 Domain Layer,因此不存在你提到的问题,你可以看下DDD的架构图,是以 Domain Layer 为中心的星状放射图。

    你不能空泛的来谈这个问题,你得具体的举出一个 Model 变动会涉及到 Controller 和 View 的示例出来。另外请记住我已经提到的话:当你的服务接口需要的的数据契约无法从业务层得到满足后,你再在服务层新建数据契约,并同实体对象做个转换。那么你的疑问是不是就是包含这个解决方案中。

    2013年1月4日 3:59
  • 刚刚注意了一下您的回答里面提到了DDD,之前不曾对DDD有了解。

    刚刚临时恶补了一下,我先说说我的理解吧:

    DDD也是分为三层,跟MVC类似:Domain对应Model,Controller对应了Application,View对应了Facade;但是Application和Facade同时依赖与Domain。

    现在我项目里面WCF服务应该算是Facade的,但是之前为了方便,逻辑写在了Facade上,很多逻辑都依赖了接口上的对象。

    现在我想将Facade上的逻辑转移出来,独立到Application中,但是问题来了:以前Model层上是用NHibernate生成的表实体对象,而且和NHibernate绑定紧密,所以我不想Facade层(甚至是Application层)上依赖与这个与NHibernate紧密绑定的实体对象。

    2013年1月4日 9:23
  • 刚刚注意了一下您的回答里面提到了DDD,之前不曾对DDD有了解。

    刚刚临时恶补了一下,我先说说我的理解吧:

    DDD也是分为三层,跟MVC类似:Domain对应Model,Controller对应了Application,View对应了Facade;但是Application和Facade同时依赖与Domain。

    现在我项目里面WCF服务应该算是Facade的,但是之前为了方便,逻辑写在了Facade上,很多逻辑都依赖了接口上的对象。

    现在我想将Facade上的逻辑转移出来,独立到Application中,但是问题来了:以前Model层上是用NHibernate生成的表实体对象,而且和NHibernate绑定紧密,所以我不想Facade层(甚至是Application层)上依赖与这个与NHibernate紧密绑定的实体对象。

    DDD跟MVC是不一样的概念,而且不是从同一个角度来考虑问题的解决方案。鉴于此,我将不再用 DDD 的概念来给出建议,而是就事论事的来谈你的问题。

    如果你不想Facade层(甚至是Application层)上依赖与这个与NHibernate紧密绑定的实体对象,那么你就需要建立新的中间对象来同NHibernate生成的表实体对象做映射。

    • 已标记为答案 JasonMing 2013年1月5日 1:33
    2013年1月4日 9:42
  • 看来这个还是最麻烦的情况了,先感谢您的回答。

    我先尝试一下。

    2013年1月5日 1:34