首先请告诉我，就架构而言，这种解决方案结构是否良好？ 我有XXXX。在中心的商业项目。 XXXX。合同项目有参考。 XXXX。服务项目有合同和商业项目的参考。
现在我希望我的服务托管在灵活的环境中。这就是为什么我想将自定义托管逻辑放在 Service > Host 文件夹中。该项目还将具有自定义实例提供工具，以便可以使用一些参数构造函数创建我的服务类。 另外我需要有不同类型的端点，所以我还有一个 Bindings 文件夹
这 3 个自定义的东西目前已经满足了我的要求。
现在请指导我使用一些示例代码 sn-p 用于 Bindings/Host/Instance
【问题讨论】：
我不知道你说的是什么
我希望我的服务托管在灵活的环境中
和
我想将自定义托管逻辑放入 Service > Host 文件夹中
使用的托管容器类型取决于服务实现所引用的项目类型（Web、控制台、Windows 服务等）。这不是您想要捆绑到一个项目中的东西，您应该有不同的每个不同的服务实例的项目（甚至是不同的解决方案）。
这导致了您的通用解决方案结构。通过将合同作为项目放置在您的解决方案中，您将合同程序集构建（以及可能的部署）耦合到解决方案的构建和部署。理想情况下，合同应该在他们自己的解决方案中，以便可以与您的服务实施分开构建和管理它们。如果有时您需要维护合约的多个版本怎么办？
我认为您创建对任何人都可以是任何东西的通用服务的方法过于复杂。您应该让 WCF 为您处理此类工作，至少为您的每个服务实现创建一个不同的项目，并将绑定管理推迟到部署时。
此外，除非您正在编写自己的自定义绑定代码，否则您不需要用于绑定的文件夹。
绑定可以（并且应该）在您交付端点时在配置中定义，并且在某种程度上，关于使用哪个传输绑定的决定应该是管理或管理而不是开发问题。
【讨论】：