在另一个c#项目中使用引用项目's WCF服务
本文关键字：项目 WCF 服务 另一个 引用 | 更新日期: 2023-09-27 18:12:07
当涉及到WCF和正常引用时，我正在努力理解某些引用方面。我有一个解决方案与4个项目。一个项目是服务，另外三个项目有对这个项目的服务引用。一个项目是一个基类库，传统上在其他三个项目中引用。
我必须按照一定的顺序更新服务引用，否则VS会对不明确的引用感到困惑。这是由于WCF引用以某种方式通过普通引用导入，因此与服务相关的所有内容都有两个名称空间。
我试图通过从除基本库之外的所有库中删除服务引用来整理这一点，因此这将是WCF连接的仲裁者，并且没有更多的歧义。然而，我不确定是否可以通过引用的方式在另一个项目中使用服务引用，并且服务会抛出未找到端点的异常。我确保项目仍然有终点，但他们现在没有参考。我假设端点将通过基本引用，但它似乎不是。现在，基库中的类也处于它们的基本版本和服务版本之间的冲突中。
基本上引用是这样的:
WCFProject ->serviceReference<- BaseLibrary ->reference<- SiteProject 1和2.
我如何得到SiteProjects使用WCF服务没有在家庭项目的服务参考，但在BaseLibrary?
对于那些偶然发现这一点的人，我找到了一种方法，使用以下SO线程使用引用的项目服务引用:无法找到默认端点元素
我认为您应该先问"为什么这些引用是服务引用，而不是二进制引用?"
这样做可能有一个很好的理由，例如，服务将部署到解决方案中其他项目的单独机器上。另一个原因是服务提供的功能不适合在进程中运行，并且会使消费应用程序过于复杂。
在您的场景中，问题将是:
"对于三个服务消费者中的每一个，我是否可以通过简单地通过二进制引用引用服务内部内容来利用服务的功能?"
如果答案是肯定的，那么通过一些重构，你可以简单地删除WCF服务库代码和服务引用。然后，您将拥有三个项目，它们在运行时都承载了所需的进程内功能。
这是可取的，有以下两个原因:
- 进程内代码比进程外代码(如wcf服务)快几个数量级。
- 进程内代码的管理和部署要简单得多。
但是，如果您确实需要将服务的功能保留在WCF服务中，那么您仍然可以通过以下方式大大简化您的解决方案:
- 将服务移动到自己的解决方案中，以及
- 去掉所有的服务引用，使用
ChannelFactory<T>.CreateChannel()直接调用服务。
ChannelFactory的工作原理是允许你通过直接引用服务二进制文件来调用服务。这样就不需要服务引用，因为服务引用没有共享的二进制依赖项。
这种方法有很多可取的原因，但这里有两个:
- 不需要服务引用，极大地简化了你的代码。
- 当服务发生变化时，无需更新任何内容;修改可以通过二进制引用获得，就像使用进程中的程序集一样自然。
我经常看到WCf服务作为解决方案中的项目包含的例子，其中解决方案中的其他项目通过服务引用使用服务。在我看来，这不是好的设计。首先，服务不应该与其消费者一起驻留在单个解决方案下，其次，消费者应该直接消费服务，除非绝对必要，否则不使用服务引用。
我不熟悉不使用参考的过程和你的解看起来很有趣。我会仔细研究的
请。在完全控制服务和消费者的场景中，服务引用没有位置。我知道这听起来很规范，但这是经验之谈。
数据库模型库驻留在BaseLibrary中，它们是服务项目参考使用
哪个项目引用此程序集?如果服务使用它，那么您可以将它与服务一起移出解决方案。但是客户也使用这个吗?如果是这样，这是否意味着客户端和服务都访问相同的数据库?如果不是，那么为什么它们都使用相同的数据模型呢?
将服务转移到另一个解决方案是否会否定这种优势只有一个地方的项目间代码?
我强烈反对为项目间代码提供一个单独的位置总是一个很好的理由，将项目集中在一个解决方案中。这样，您就可以结束彼此完全无关的项目(从业务、技术或功能的角度来看)，共享一个解决方案，这样它们就可以从这个"优势"中受益。在我看来，更好的策略是将公共程序集删除到它自己的解决方案中，然后将其发布到本地NuGet服务器。任何需要此程序集的项目都可以从NuGet中检索它。