Prism 中的模块应该有多细粒度？
我目前正在使用 Prism（复合应用程序库/指南）开展我的一个项目。 该应用程序将是一个专门的类似于 MSPaint 的篮球应用程序（球、球员等的预定义对象）。
现在我想知道如何将我的应用程序组织到 Prism 模块中。 尤其是在考虑软件的绘图部分时。
我是否应该将通用绘图视图（2 列：工具箱、画布）拆分为 2 个模块（工具箱和画布），或者这些模块的持续通信所产生的开销是否会太大？
Prism 模块到底应该有多细？
预先致谢并致以诚挚的问候， 克里斯楚
I am currently working on a project of mine using Prism (the Composite Application Library/Guidance). The application will be a specialized MSPaint-like application for basketball (predefined objects for balls, players etc.).
Now I am wondering how to go about organizing my application into Prism modules. Especially when thinking about the drawing part of the software.
Should I split the general drawing view (2 columns: toolbox, canvas) in 2 modules (toolbox and canvas) or would the overhead created by the constant communication of these modules be too overwhelming?
How fine grained should Prism modules really be?
Thanks in advance and best regards,
crischu
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
当您分成模块时，开销非常小。
我会选择帮助您组织解决方案的方法，而不是非常担心性能方面的考虑。 如果您发现模块给您带来麻烦或者您发现两个模块确实属于在一起，您可以轻松地组合模块。
规则是：
让它运行。
使其正常运行。
让它跑得快。
以该顺序。 首先做感觉良好的事情，然后在必要时进行重构。
There's very little overhead when you separate into modules.
I would go with what helps you organize your solution, rather than worrying very much about performance considerations. You can easily combine modules if you find they are causing you trouble or you are finding that two modules really belong together.
The rule is:
Make it run.
Make it run right.
Make it run fast.
In that order. Do what feels good first and refactor later if necessary.
我想说这取决于您如何通过 UI 分配应用程序的功能。 如果您只有一个屏幕，但有多个部分管理不同的功能，则每个部分（选项卡页、面板等）都应该有自己的模块。 StockTrader RI 或 NewsAggregator 示例就是这种情况。
但在我们正在开始的项目中，我们决定有多个页面，每个主要功能一个页面，并在它们之间进行导航。 在这种情况下，一个模块将代表一个页面，不会比页面更小。
I'd say it depends on how you distribute the functionality of your application over the UI. If you have just one screen, but with multiple sections that manage different features, each of that section (tab page, panel, etc) should have it's own module. This is the case with the StockTrader RI or NewsAggregator samples.
But on the project we are starting we decided to have multiple pages, one page for each major feature and to have navigation between them. In this case, a module will represent a page, nothing smaller than that.