我正在制作一个由Screens（Presenter + View）组成的WPF应用程序。我希望能够在配置文件或SQL数据库中声明这些屏幕。我一直试图找到一个很好的解决方案，我已经放弃了，并且问你们有些人如何设计这类东西？我已经在这工作了一个多星期，每一个解决方案都让我觉得很臭。
在我的WPF应用程序中，我有一个表示屏幕的树视图。当用户单击某个节点时，将加载该屏幕。我希望能够从配置文件或数据库填充treenodes。程序不应该关心这些存储的位置，因此我可以换出数据库存储的配置存储。如果我存储了屏幕信息，我也可以使用IOC容器为我实例化屏幕并按名称检索它们。以下是我提出的配置文件架构示例：
<screen name="" title="" presenterType="" viewType=""/>
<screen ...>
<screen .../>
<screen .../>
</screen>
<screen .../>
我提出的最新解决方案是使用一个ScreenService，向ScreenInfo询问ScreenInfo对象。然后，我将能够使用此信息填充treeview和IOC容器。
听起来这是一个很好的解决方案吗？你会做什么不同的？而且，您如何在自己的编程中设计这种系统？
答案 0 :(得分：0)
通常，您需要为这些类型的情况使用工厂模式。 ScreenService，ScreenRepository和Screeninfo的混合听起来就像你钉它一样。 Here是工厂模式的基本概述。您可以使用维基百科文章作为起点来查看您是否遗漏了任何变体或方面。
我设计并维护了一个CAD / CAM应用程序，该应用程序具有多个固有参数化形状的库，用户可以在其中键入几个维度并计算切割形状。每个形状都有自己的屏幕设置。我在启动应用程序时使用了类似的模式。
我扫描每个程序集的形状库目录，选择具有检索形状列表的方法的工厂类，将其加载到主列表中。当用户单击工具栏按钮或从列表中选择时，软件然后使用键从列表中拉出正确的形状，从而暴露出IShapeScreen接口。管理形状的表单使用该界面为该形状绘制正确的输入屏幕。
这种方法已经工作了近十年而没有任何重大问题，同样重要的是没有给我留下“哦，我希望我在设计时做到这一点”的感觉。所以我认为你走在正确的轨道上。
请注意，您可能不需要使用基于文本的配置文件。使用属性，您定义的某些接口和.NET反射API，您可以将DLL放在一个目录中，软件可以扫描该目录并正确地拉入所需的对象。在你的案例中屏幕对象。但是，如果您希望人员编辑配置，则肯定需要基于文本的文件。我假设您使用.NET标记.NET。
答案 1 :(得分：0)
抱歉，我应该提到我使用的是.NET 3.5。我很习惯在ASP.NET论坛上发帖忘记了。
我喜欢扫描程序集的想法，但我想将它定义为填充树视图的层次结构。此外，与配置文件或数据库相比，使用反射扫描程序集会有什么性能损失？它是一个显着的差异还是那么轻微的没有人能说出来的？
我正在创建的应用程序将在我们公司内部使用。它需要具有导航的层次结构，因此我们的屏幕很容易找到。扫描一个程序集文件夹会很好，因为我们可以创建一个模块并通过它进入该文件夹，应用程序会自动拾取它。这将导致以分层方式表示屏幕的问题。此外，我们希望实施授权，以便用户只能看到允许使用的屏幕。
感谢您的回复。我喜欢看别人怎么做。它帮助我理解了很多这些设计概念，因为我刚刚开始设计模式的路径（刚刚订购了PEAA书）。其他人请分享你的想法。它也可以帮助像我这样的人偶然发现这个问题。
答案 2 :(得分：0)
当您从工厂方法返回对象时，您也可以包含层次结构。例如，我的形状工厂有两个方法一个返回添加到主列表的形状列表，另一个返回形状库。虽然用户可以定义和更改实际库，但我有一个自动生成的默认集，用于故障排除和初始安装。它是分层的。
然而，ShapeLibrary由ShapeLibraryItem组成。 ShapeLibraryItem有一个存储在其中的键，因此它可以将形状拉出主程序列表。因此，单击一个按钮或项目，它会查看与之关联的ShapeLibrary项目。获取密钥，使用密钥获取形状程序，然后使用UI界面绘制屏幕。
如果您的屏幕将层次结构信息嵌入为其中一个属性之一，那么我建议您将其分离为层次结构项。然后可以创建由HierarchyLists OR HierarchyItem组成的HierarchyList。我会创建一个IHierarchyItem接口，以便HierarchyLists看起来像一个项目。
主要区别在于行为。当您单击HeirarchyList将显示另一个列表（或展开等）时，真项将显示一个屏幕。
所以你的程序集将有两个标记有两个属性之一的类。一个是ScreenFactory，另一个是HierarchyFactory。
请注意，您不必使用可以直接将HierarchyItem链接到形状的键。我使用GUID键来避免每次都耦合。耦合并不总是坏的，但它也不总是好的。由于GUID实际上是唯一的，因此它的效果相同。
至于性能，在你注意到它之前，你将需要数百个ASSEMBLIES。请记住，您不必为每个屏幕都有一个程序集。只需将它们逻辑地分组到少数几个组件中，你就可以了。