代码之家  ›  专栏  ›  技术社区  ›  tucaz

设计wcf数据契约和操作

  •  4
  • tucaz  · 技术社区  · 15 年前

    我开始设计一款WCF服务总线,虽然现在很小,但随着业务的发展,它会不断增长,所以我很担心一些问题,也尽量不让Yagni太多。这是一个电子商务平台。问题是我对放东西的地方有太多的想法。我将给出一个场景来演示我的所有问题。

    我们有一个电子商务网站,销售产品并最终交付。为此,我们有一个PlaceOrder服务,除了其他参数外,它期望一个地址对象,在此上下文中(我们的网站下订单)由City、Street和Zipcode组成。

    我们还与仅使用我们的平台销售产品的合作伙伴开展业务。他们负责送货。在这个场景中,我们有一个placeorderforpartner服务,其中包括一个address对象。但是,在此上下文(合作伙伴下单)中,address对象由不同的信息组成,这些信息仅与合作伙伴下单相关。

    在这种情况下,我有几个问题:

    1)在我的解决方案中,如何在名称空间和文件夹中组织这个datacontracts对象?我考虑为每个上下文(合作伙伴、客户等)设置一个文件夹来保存服务和数据契约。

    所以我会

    - MySolution.sln
    -    Partner (folder)
    -        PartnetService.svc
    -    DataContracts (folder)
    -        Address
    -    Customer (folder)
    -        Customer.svc
    -    DataContracts (folder)
    -        Address
    

    使用这种方式,我将有一个命名空间来放置所有特定于上下文的数据契约。

    2)服务设计呢?我是否应该为每个可能放置和排序的服务创建一个服务,并在其中创建一个placeOrder方法,如下所示:

    partner.svc/订单
    customer.svc/订单

    或者使用placeOrderForPartner和placeInternalOrder创建订单服务,如下所示:

    order.svc/placeOrderForPartner订单
    订单.svc/placeorderforcustomer

    3)假设我在最后一个问题中选择了第一个选项,那么我应该如何处理在订单上进行的对合作伙伴和客户通用的操作?

    4)我是否应该将datacontracts和服务定义放在同一个程序集中?每人一个?服务实现的一切?

    5)如何命名操作的输入输出消息?我应该使用实体本身还是使用operationnamerequest和operationnamereponse模板?

    归根结底,我最大的问题是:如何“组织”服务创建中涉及的数据契约和服务?

    提前谢谢你的任何想法!

    2 回复  |  直到 15 年前
        1
  •  10
  •   marc_s    15 年前

    除了TomTom提到的,我还想在这里加上我的2美分:

    我喜欢这样构造我的wcf解决方案:

    合同 (类库)
    包含所有服务、操作、故障和数据契约。可以在纯.NET到.NET方案中在服务器和客户端之间共享

    服务实现 (类库)
    包含实现服务的代码,以及实现此功能所需的任何支持/帮助程序方法。没别的了。

    服务主机 (可选-可以是Winforms、控制台应用程序、NT服务)
    包含用于调试/测试或可能也用于生产的服务主机。

    这基本上给了我服务器端的东西。

    在客户端:

    客户端代理 (类库)
    我喜欢将我的客户端代理打包到一个单独的类库中,这样它们就可以被多个实际的客户端应用程序重用。这可以使用svcutil或“add service reference”来完成,并手动调整结果糟糕的app.config,或者使用 ClientBase<T> ChannelFactory<T> 构造。

    1-n个实际客户 (任何类型的应用程序)
    通常只引用客户机代理程序集,如果共享,也可能引用合同程序集。这可以是asp.net、wpf、winforms、控制台应用程序、其他服务-您可以命名它。

    这样;我有一个漂亮干净的布局,我一次又一次地使用它,我真的认为这使我的代码更干净,更容易维护。

    这是米格尔·卡斯特罗 Extreme WCF screen cast 在Dotnet摇滚电视与卡尔富兰克林-强烈推荐屏幕演员!

        2
  •  1
  •   TomTom    15 年前

    你在最高层就开始犯错了。

    • 它不应该是“placeorder”服务,而是“ordermanager”。也许你以后想增加更多的服务功能——比如查询订单、取消订单、变更订单——谁知道呢。一般来说,我会保持“services”(.svc)的数量很小,并在那里添加方法。否则,在代码中使用它们会带来巨大的开销——没有任何实际好处。

    • 为什么要将合作伙伴和客户分开?我确信,有了15分钟的数据设计,你可以把事情分解成一个数据结构,这样你就只能有一个服务了。如果不是…将这两个方法放在一个接口上,受安全性限制。但我真的不想有两个这样的节目。而是有两个地址字段-“address”和“partnerinfo”,并且只能设置一个(其他字段必须为空),在逻辑中选中。

    • 分成两个项目。接口、数据契约进入一个单独的项目(blabalbla.api)中,这样客户可以根据自己的需要实际获得dll——至少这会让您的工作更轻松,您可以依赖“共享类型”,无需在内部生成包装器。允许更好的测试(因为子项目不要忘记重新生成包装…在测试时可能会导致错误)。

    • 我总是把实现放在一个“blabla.service”项目中。url在一个子域(或“api.blabla.com”,主要取决于心情,但最近我主要使用的是api)中是“services.blabla.com/”,将内容从主网站中分离出来。