Reputation: 513
I am currently working on a WCF project, that contains 4 different components. None of the components are inter-related.
Currently I've made one project and included the four services. I realized that if one of the components changes, we would have to test the entire project to be on the safe side.
Whereas if I make 4 different projects, they are not related to each other or talking to each other, that would make testing and integration a lot easier. And if we are changing one project, other projects would not be affected or go down.
I need some feedback with pros and cons.
Again, the components don't talk to each other or make any calls to each other.
Upvotes: 3
Views: 2041
Reputation: 31760
Each service should be building to it's own assembly, and when deployed should run in it's own app pool. After that it doesn't really matter if the projects are all part of the same solution.
Upvotes: 0
Reputation: 286
definitly different assemblies. it will reduce the loose coupling.
If they share some common infrastructure (error handling, logging, behaviors...) use a 4th commom assembly.
It wont impact the way you deploy your services. If they are meant to live inside the same web application in IIS, then they simply will be 3 assemblies in the bin. the servicemodel config wont change. If they will live in separate applications, then its even better
If you think 3 services is still mantainable, think about 10... as you said, one little change in one of them is a ne version for all of them
The fact they aretalking (or not) together doesnt impact, since they are services, not components
on the other hand, when dealing with lots of services, one of the solutions is building a service bus, and then, your services are just regular classes, and it less matters wheteher they are in the same assembly or not (even could be easierin same assmebly)
but in your scenario, definitly different assemblies
Upvotes: 3