我的团队的目标是在当前架构不足的情况下对REST API WCF系统进行重构。我们希望将现有的WCF服务划分为表示应用程序的实际业务上下文的模块。 据我所知,单个服务(意为单个.svc文件)只能有一个合同接口的实现 - 可以有多个合同,但它们必须全部由同一个类实现。
重构背后的想法是将现有的WCF划分为负责特定业务上下文的功能块(模块),并在单独的项目中将每个WCF实现为不是WCF服务的普通.dll。它们将在一个“核心”WCF服务中全部“链接”在一起 - 最有可能在app.config中定义或由DI容器作为普通依赖项注入。因此,每个项目都将包含一个契约接口(包含所有WCF装饰属性),并将其实现应用于特定模块。
不幸的是,由于第一段中描述的问题 - 每个服务一个实现,这个想法不会起作用。将实现创建为部分类的想法将不起作用 - 模块必须是单独的项目 - 部分将不起作用。用于evry模块的单独WCF服务也不是一种方法 - 变更需要对FE透明,并且我们有sevreal这样的服务,这将意味着几个现有服务x 5-6上下文 - 没办法。
有没有人有这种WCF方法的经验? BTW用其他方式替换WCF是一个问题。
此致
答案 0 :(得分:0)
制作一些适配器类。
每个适配器都会引用一个服务接口并将请求转发给实际的类。