推荐的 Prism v2 Silverlight/WPF 项目结构
我目前的任务是向我工作的公司中的所有开发人员教授有关 Silverlight (v2) 的知识。 唯一的问题是我自己没有任何真正的 Silverlight 经验。 当然，我已经研究了有关数据绑定、布局等内容的所有技术细节，因此我可以帮助我的同事。 但很难找到任何信息的一件事是一般项目结构。
我决定遵循 P&P Prism 2 路径（甚至可能稍后会加入一些 WPF），所以我想知道你们中是否有聪明人有使用 Prism 2 开发真实项目的经验，甚至只是WPF，您对项目/解决方案结构有什么建议吗？ 例如“您将视图放在哪里？” 或“你们有模块项目命名约定吗？” 等等。
任何帮助将不胜感激。
I'm currently tasked with teaching all the developers, in the company I work in, about Silverlight (v2). The only problem is that I don't have any real Silverlight experience myself. Of course I've studied all the technical details about stuff like databinding, layout etc. so I can help my colleagues. But one thing that is hard to find any information about is the general project structure.
I've decided to follow the P&P Prism 2 path (and maybe even throw some WPF in the mix later on) and so I was wondering if any of you clever people have experience in developing a real project using Prism 2 or even just WPF, and if you had any suggestions about the project/solution structure? Such as "Where do you put views?" or "Do you have any module project naming conventions?" etc.
Any help will be greatly appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这纯粹是基于我使用 Prism for WPF 的经验，而不是 Silverlight。 我不是 Prism 专家，很容易改变我对其中一些的想法。 :-)
为所有东西创建一个模块是很诱人的。 不。 您的构建时间很快就会耗尽，而您只能处理一个非常支离破碎的解决方案。 相反，我有一个主模块，它是静态加载的，并且包含基础包中我想要的所有内容。 任何附加组件或附加组件都会成为动态加载的其他模块。 可能值得将该模块稍微分解一下，但要保持较小的数量。 这也有助于缩短加载时间。
不确定这是否是个好主意，但我喜欢将 View 和 ViewModel 接口保留在与 View/ViewModel 本身相同的文件中。 我喜欢这个，因为 MVVM 模式可以生成大量文件，这可以减少文件计数。 缺点是接口和它的实现更难分开，但我不太可能需要这样做，而且这种技术不会干扰测试，这是另一个好处。
视图往往会进入视图文件夹，然后每个视图都有一个文件夹。 每个视图的文件夹包括视图、ViewModel 和 Presenter（如果需要）。
从参考实现中，为需要在模块之间共享的所有公共类创建一个基础结构项目。 参考实现有更多细节，但这可以用于各种事物，例如公共服务接口、常量等。
This is purely based on my experience using Prism for WPF, not Silverlight. I'm not an expert at Prism and could easily change my mind on some of these. :-)
It's tempting to make a module for everything. Don't. Your build time will quickly blow out and you're left dealing with a very fractured solution. Instead I have one Main Module, which is loaded statically, and contains everything I want in the base package. Any addons or extras become other modules that are loaded dynamically. It might be worth breaking that one module down a bit, but keep the number small. This also helps with load time.
Not sure if this ones a good idea, but I like to keep the View and ViewModel interfaces in the same file as the View/ViewModel themselves. I like this because the MVVM pattern can produce alot of files, and this keeps the file count down. The down-side is that the Inteface and it's implementation are harder to separate, but I'm unlikely to need to do this, and this technique doesn't interfere with testing, which is the other benefit.
Views tend to go into a Views folder, then a folder for each View. The folder for each View includes the View, the ViewModel, and the Presenter if one is needed.
From the reference implementation, make an Infrastructure project for all common classes that need to be shared between modules. The reference implementation has more details but this can be used for all sorts of things like common service interfaces, constants, etc.