我是一个重写20多年历史的PowerBuilder 2.0应用程序的团队的一员。应用程序非常庞大，无法对新系统进行彻底切换。当我们用新的.Net代码慢慢替换旧功能时，我们被迫集成了这两个系统。
基本上，我们的新应用程序是使用WPF / MVVM编写的。我们写了一个COM-visible＆＃34;适配器＆＃34; PowerBuilder代码用于打开.Net事务的类（视图）。适配器具有旧代码调用的OpenTransaction(string transactionName)，并使用反射来查找具有相应名称的视图。用户导航完全在旧代码中进行。
我们的每个.Net交易均继承自ViewBase的{{1}}。最终（当我们替换了所有遗留代码时），我们打算在具有模态导航窗口的单个Shell中的选项卡控件中打开所有事务。但是现在，每个事务都在自己的窗口中打开，其中包含一个＆＃34;内容＆＃34;区域。
我们刚刚开始使用PRISM进行探索，我的问题是，除了细分我们的Shell并定义我们的应用程序的主要用户界面的总体布局（我们真的做不到现在），有没有理由使用PRISM区域和/或导航？
我们的一位团队成员确信我们应该使用区域来细分我们的观点。例如，我们有一个＆＃34; MaintainColors＆＃34;在此交易中进行交易（使用＆＃34; MaintainColorsViewModel＆＃34;）
UserControl属性他认为这些应该都是PRISM区域，应该作为我们的SelectedColor的DataTemplates实现，并且我们应该有一个＆＃34;泛型＆＃34; MaintainColorsViewModel交易。他的观点是，我们可以通过交换ViewModel并加载适当的DataTemplates，对不同类型的项使用相同的Maintain事务。
我的论点是这些＆＃34;模板＆＃34;不会重复使用，并且与特定类型的ViewModel绑定。我们仍然需要定义我们的选择＆＃34;选择＆＃34;和＆＃34;编辑＆＃34;区域看起来像（所以我们不会减少代码）并且它不像我们将要使用＆＃34; EditIndividuals＆＃34;模板与＆＃34; SelectColor＆＃34;模板。
我在这里缺少一些东西吗？