Spring.net 配置文件和程序集的依赖差异
在 Spring.net 的许多示例中，都嵌入了用于配置元数据的程序集资源文件。每个程序集都有自己的配置元数据文件。 这些文件包含对象定义以及对其他程序集中的对象定义的对象引用。这会在程序集之间创建依赖关系。
我应该为 Spring.net 配置元数据使用嵌入式程序集资源吗？
嵌入式程序集资源文件是否应该移入单独的程序集？
用例：
程序集依赖关系： 
配置依赖项： 
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:
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
将配置元数据集中到单个程序集中还是将其分解为单独的程序集的决定在很大程度上取决于您的特定用例（并且具有通常的优点和缺点关联。集中式以便于参考与分散式-根据我的经验，针对狭窄范围的变革策略）。
但是，我确实有一个问题：配置元数据文件之间的依赖关系不会模拟/镜像程序集中的实际类型依赖关系吗？
举个例子：如果AssemblyA.Type1依赖于AssemblyB.Type2，并且每个程序集中都有一个配置文件，创建“配置文件的依赖关系”，你不是吗？在大多数情况下，由于编译器需要解析您的类型，无论如何已经具有相同的程序集依赖性？
我试图理解其中存在程序集依赖关系的用例，该依赖关系仅是嵌入式配置文件中对象定义的结果，并且无论如何也不需要存在 b/ c 相关程序集中已有的代码中的类型依赖关系...您有一个吗（您可以向我解释一下，以便我可以更好地理解用例）吗？
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)?