WCF服务代理名称/命名空间命名策略

Question

WCF服务代理名称/命名空间命名策略

wcfweb-servicescoding-stylenaming-conventionsproxy-classes

4

请问有没有一种对于服务代理类起名的策略是比较好用的呢？

例如，如果我有两个项目中的三个web服务，它们分别如下：

XWs
  AService.asmx
YWs
  BService.svc
  CService.svc

你会使用什么作为AService、BService和CService的服务引用名称和命名空间？

通常情况下，我希望代理名称/命名空间中有一些内容表明所使用的内容不是具体类，而是代理对象，这样既不会与具体类的使用发生冲突（并强制使用别名或命名空间限定的类名），也不会隐藏存在跳转的事实（我想Wcf服务代理生成器的默认后缀Client可以覆盖这一点）。同样重要的是，它能处理编写包装器/桥接服务的情况，该服务将[sub]集合的调用转发到另一个已引用的服务。

我使用过各种风格（添加Ws、ServiceProxy、Ref或Proxy后缀？以ServiceName.为前缀），但从未完全满意。

你用过哪种方法？是否有风格指南提到了命名策略？

编辑：虽然Cheeso的回答涵盖了我的大部分问题，但我仍然对以下问题的答案感兴趣：

1.如上面的示例那样给代理类命名空间命名的策略 2.提到代理的命名策略的样式指南

- Ruben Bartelink

2个回答

1

我也在这里探索选择。我刚读了Miguel Castro的this article，他建议分离服务、服务主机、数据契约和服务契约，并且我主要想决定是否应该将所有服务契约保留在单独的契约命名空间中，还是让它们存在于每个服务命名空间中。将它们分离到自己的命名空间中的原因是，如果其他服务使用它们，则它们处于更中立的位置。

例如：

companyname.services.contracts.service1contract
companyname.services.service1

或者这样：

companyname.services.service1
companyname.services.service1contract

- Tone

我不会选择 'companyname.services.contracts' 这条路线 - 记住任何适当的服务都应该是完全自治的。拥有一个中央的 'contracts' 空间就像拥有一个 utils 项目 - 每个人都堆积在一起，最终你会得到40%的良好质量和60%的使用率，但却没有解决方法。即使在您的树中有一个 'Services' 基础也值得商榷。 - Ruben Bartelink

更进一步来说，公司名称的部分是有争议的 - 如果你合并了呢？你想让人们重新命名吗？如果你重新设计标识呢？如果你收购了另一家公司或者被收购了 - 后期服务中有一半在不同的命名树下是至关重要的吗？只是说一下而已；你需要一个'companyname.services'的东西，这样你就有了与你接触的其他程序集冲突的机会。但请记住，真正的命名空间是在你的契约中的WSDL命名空间。 - Ruben Bartelink

我的问题显然是关于客户端的事情，这正是我在米格尔的文章中快速浏览到的内容。因此，总结一下，我会选择一个FamilyRootIfService1IsPartOfAFamilyOfServicesButNotJustACompanyNameIfItCanBeAvoided.Service1.Contracts。如果您要将每个服务的合同放入命名空间和项目中，则应选择Root.Service1.Contracts（而不是Service1Contracts），以便清楚地表明Service1.Contracts和Service1之间的关系。并且将您的程序集、.csproj和项目目录命名为与命名空间完全相同：R.S1.Contracts。 - Ruben Bartelink

希望以上内容能够引发一些思考。我相信还有更深入的关于命名空间的讨论。我对自己目前的想法非常满意，但是我已经在这个“愚蠢”的讨论上花费了很多时间！ - Ruben Bartelink

这是很好的反馈。谢谢你的想法，Ruben。我同意这似乎是一个愚蠢的讨论，但实际上比它表面上看起来的更重要。 - Tone

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Cheeso · Accepted Answer

原本我使用了像ServiceNameProxy和ServiceNameSvcProxy这样的名称。但是，就像您一样，我对这些名称并不满意，因此我没有坚持使用它们。现在我只使用ServiceNameService或ServiceNameSvc。

您想向类的用户传达的关键信息是“该类是代理”吗？你所做的区分-代理类和具体类之间的区别-似乎应用于鳄鱼和鳄鱼。具体的相反是抽象的，不是吗？而svcutil.exe生成的代理类实际上是具体的。

通过命名约定，我认为您试图表明代理类与远程服务通信。(当我们称其为“代理”时，我们的意思是指它站在某物前面，在这种情况下是远程服务。)如果是这种情况，那么为什么不使用ServiceNameService或ServiceNameConnection或类似的方式呢？就像System.Data.OleDb.OleDbConnection或System.Data.SqlClient.SqlConnection。

我自己选择的命名约定符合这一点。它表明该类表示一个服务，该服务被假定为远程服务。我并不太关心强调它是代理到服务的事实。出于实际目的，它是一个服务是关键。