My Team is aiming to perform refactoring of our REST API WCF system as current architecture insufficient. We would like to divide existing WCF services into modules representing the actual business context of the application. As far as I know a single service (meant as a single .svc file) can have only one implementation of contract interface(s) - there can be several contracts but they must all be implemented by the same single class.
The idea behind refactoring was to divide existing WCF into functional blocks (modules) responsible for particular business contexts and implement each of them in separate project as a plain .dll that is not a WCF service. They would be all "linked" together in one "core" WCF service - most likely defined in app.config or injected by DI container as an ordinary dependency. So every project would contain a contract interface (with all WCF decoration attributes) and its implementation applying to a particular module.
Unfortunately, the idea won't work because of problems described in the first paragraph - one implementation per service. The idea of creating the implementation as partial class won't work - modules must be separate projects - partial won't work. A separate WCF service for evry module is also not a way to go - the change needs to be transparent for FE, and we have sevreal such servces and this would mean several existing services x 5-6 contexts - no way.
Has anybody had experience with such approach to WCF ? BTW replacing WCF with sth else is out o a question.
Regards
