最佳实践 WPF Prism 资源

发布于 2024-09-26 06:34:20 字数 183 浏览 4 评论 0原文

我有一个带有几个模块的 WPF prism 桌面应用程序。过去,我将所有本地化资源放在基础设施程序集中的公共资源文件中,并在所有模块中引用它。

但最近我一直想知道从维护的角度来看这是否确实是正确的方法。从本质上讲,它也破坏了模块化。从长远来看,在模块本身中包含模块特定的资源文件是否是更好的方法?

所有的想法都受到赞赏。

I have a a WPF prism desktop app with a few modules. In the past I've put all my localized resources in common resource files in the infrastructure assembly and referenced it in all modules.

But lately I have been wondering if that is indeed the right approach from a maintainence perspective. In essence it also sort of breaks modularity. Would having module specific resource files in the the modules themselves be a better approach in the long run?

All thoughts appreciated.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

悍妇囚夫 2024-10-03 06:34:20

就 Prism 的主要目标之一是模块化而言,将资源仅放在适当的组件中似乎是显而易见的。通过一个集中的组件共享资源与模块化相反。
当您想要添加更多(可选)模块时,以集中方式执行此操作将给您带来另一种类型的 DLL 地狱。您必须在不了解使用该程序集的模块的情况下更新该公共程序集。并且再次确定存在哪个模块违反了模块化本身。另一种方法是始终将公共程序集更新到最新版本。
无论您做什么,遵循集中式方法都会迫使您构建向后兼容的所有模块。

这是我目前的观点。但就我与 Prism 合作仅几周而言,我不太确定我的声明是否是应该的方式。

As far as one of Prism's main targets is modularity it just seems obvious to put your resources only in the appropriate assembly. Sharing resources via one centralized assembly is the opposite of modularity.
Doing it the centralized way will get you another type of DLL hell at the time you want to add more (optional) modules. You will have to update the common assembly without the knowledge of the modules that use the assembly. And determining which module is present just again violates the modularity itself. The other way is to always update the common assembly to the latest version.
Whatever you do, following the centralized approach forces you to build all your modules backward-compatible.

This is my point of view at the moment. But as far as I'm working with Prism for only a few weeks now I'm not quite sure if my statement is the way how it should be done.

守不住的情 2024-10-03 06:34:20

使用 Prism 时,我从来没有在各个模块之间进行引用(除非一个模块确实是另一个模块的增强)。我倾向于将共享资源、接口等放在一个“通用”程序集中,该程序集由所有模块和包含 shell 的程序集引用。然后通过 IoC 容器检索实现接口的事物,并将实现放置在它“所属”的模块中。

正如您所写 - 将它们放在基础设施模块中打破了 Prism 背后的想法之一。

I never have references between the individual modules when using Prism (unless one module is indeed an enhancement of another). I tend to put shared resources, interfaces etc. in a 'common'-assembly that is referenced by all modules and the assembly containing the shell. Things that implement an interface is then retrieved via the IoC-container and the implementation is placed in the module where it 'belongs'.

As you write - having them in the infrastructure module breaks one of the ideas behind Prism.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文