I know there have been countless discussions about this but I think this question is slightly different and may perhaps prompt a heated discussion (lets keep it friendly).
The scene:
I am developing a system as a means for me to learn various concepts and I came across a predicament which my brain is conflicting with. That is whether to keep my interfaces in a separate class library or should they live side by side my business objects.
I want to expose certain objects via WCF, however refuse to expose them in its entirety. I am sure most will agree exposing properties such as IDs and other properties is not good practice but also I don’t want to have my business objects decorated with attributes.
The question:
Essentially, I’ll be having a separate interface for each of my objects that will essentially be exposed to the outside world (could end up being quite a few) so does it make sense to create a separate class library for interfaces? This also brings up the question of whether adapters should live in a separate class library too as ideally I want a mechanism from transferring from one object to the other and vice versa?
1
Reasons to use a separate interface library:
- The interfaces rarely change.
- There are third party (outside company) consumers of those interfaces, and they don’t need the implementation library.
- To reduce dependencies in interface consumers: they only have dependencies on the types used within the interfaces, so they may require less assembly references.
Reasons to put the interfaces in the same library as the implementation:
- You only have to distribute one library.
- You can hide the implementation completely — the implementation classes, and supporting types, can be internal. The interfaces are public, if you need them to be public. In some cases, you can make the WCF interfaces internal as well.
- Because there is only one library, the interfaces and implementation class versions are always in sync.