In many examples of Spring.net are embedded assembly resources files used for the configuration metadata. Every assembly has its own configuration metadata files.
These files contains object definitions with object references to object definitions in other assemblies. This creates dependencies between assemblies.
Should i use embedded assembly resource for Spring.net configuration metadata?
Should the embedded assembly resource files be moved in to a seperate assembly?
Use case:
Assembly dependencies:
Config dependencies:
The decision to centralize you configuration metadata into a single assembly vs. decompose it into separate ones depends heavily on your specific use-case (and has the usual pros and cons assoc. with any centralize-for-ease-of-reference vs. decentralize-for-narrow-focused-scope-of-change strategy in my experience).
I do have a question however: wouldn’t the dependencies between configuration metadata files mimic/mirror the actual type dependencies in the assemblies anyway?
As an example: if AssemblyA.Type1 depends on AssemblyB.Type2 and you have one config file in each of the assemblies creating a “dependency of config files” wouldn’t you in most cases already have the same assembly dependency anyway because of the compiler needing to resolve your types?
I’m trying to understand the use-case where there would be an assembly-dependency that would only be the result of object definitions in embedded config files and wouldn’t also need to be there anyway b/c of the type dependencies in the code already in the assemblies in question…do you have one (and can you explain it to me so that I can better understand the use-case)?