我可以在WPF上使用MVVM模板来解决这个问题吗？

Question

我一直在阅读WPF上的MVVM。 只要我理解正确，在MVVM中我应该将模型（数据显示）从显示它的方式（视图）中分割出来，使用ModelView链接两者，对吧？

所以我想要做的是使用DataSet作为Model，其中n个字段来自数据库。 字段名称，类型和顺序是可变的（是从SQL Server视图中选择）。

该视图将是一个带有Datagrid的WPF表单。

因此，我应该以一种方式构建我的模型视图，该方法迭代DataSet中的每个字段，并根据字段类型格式化数据，以便稍后在网格上显示它。

可以在WPF上使用MVVM Templante吗？

提前致谢

UPDATE

根据LordTakkera的评论，我将尝试澄清我的情景和我尝试做的事情。 我正在使用.NET技术构建一个Client-Server Layered应用程序。 客户端和服务器将位于不同的计算机上，与WCF通信。 一些不同的客户端将使用此软件，因此假设这种情况：客户端1,2和3需要在网格上显示销售报告。

客户1需要：销售日期，客户名称和销售进口。

客户2需要：销售日期，供应商名称和销售导入。

客户端3希望在其客户端表中添加一个数字字段，该字段表示每个客户的预期销售额以及在销售报表中显示它的内容。

如果我使用强数据类型，我需要为每个客户端使用一个二进制文件，我是不是很好？ 我想要的是为客户端1,2和3使用相同的二进制文件，根据数据库数据更改销售报告的输出。

为什么？ 很多原因：

1）消除错误：如果我在某个类中发现了一个错误，我可以更正它，重新编译并将更正的二进制文件提供给我的所有客户端。

2）可伸缩性：如果我向客户端1询问的系统添加一些功能，我可以将该功能提供给我的所有客户端。

3）灵活性：我可以使用相同的二进制文件更改每个客户端的软件行为。

我理解强类型的优点，事实上我会在某些情况下使用。 但在其他方面，灵活性对我来说至关重要。 那么，这是我的选择吗？

谢谢！

更新2

在@LordTakkera和该页面中的许多人的帮助下，我设法开始开发我的应用程序。 Rigth现在我有我的模型，我的wcf服务我的客户端和我的第一个ViewVodel和View。 现在我正在尝试为应用添加更多复杂性，为我的项目添加多个XAML视图。 如果我继续关注MVVM模式，那么这些页面与插入所有其他视图的主页面之间的导航也应该使用viewModel进行管理（Something call application viewModel for read read）。 我的想法是让容器MainPage具有一个可以显示子视图的区域。 我也想在分离的XAML文件中使用子视图，因为有些视图非常复杂，我会丢失视图！ 问题是在MVVM模式上使用主容器页面找不到WPF导航的单个示例代码。 我能找到的所有示例代码：

1）使用像Prism或MVVM ligth这样的外部工具包，现在我不想用新东西搞乱！

2）每个视图的所有控件都在单个XAML上创建。

我需要一些代码的帮助来创建我的应用程序的基本布局，并想知道我的计划是否甚至是可行的。 谢谢！

Answer 1

正如HighCore所指出的那样，DataSet并不是一个很好的模型选择，但除此之外听起来不错，但我会从你的帖子中提出一些问题。

1. 你提到你有变量“类型”这是一个大红旗。 如果您有可变类型，那么您将如何在数据网格中拥有一致的列？ 现在，如果你的意思是你将为每种类型（可能使用类型化的数据模板）设置不同的数据网格，那就没问题了。

2. 当您说“格式化数据”时，我希望您的意思是“将其存储在数据对象中”。 WPF绑定到对象的属性，因此您的数据网格应如下所示：

    <DataGrid ItemsSource={Binding DataItems}> <DataGrid.Columns> <DataGridTextColumn Header="Name" Binding="{Binding Name}"/> ... </DataGrid.Columns> </DataGrid> 

基本上，请确保绑定到从模型中填充的对象。 ViewModel绝对是应该执行此转换的对象。

更新

我为不理解您的应用程序的目的而道歉，在该特定应用程序中，您所谈论的内容更有意义。 话虽如此，我会尽力解决您的疑虑：

1. 通常，如果基础数据上下文或对象发生更改，则应该更改模型/视图/视图模型。 C＃是强类型的，WPF的重点是具有声明性的，强类型的UI。 我知道您正在尝试显示“通用”数据，但除非您正在执行“SELECT *”类型查询，否则您将需要更改某些代码。 如果您知道要显示的视图是什么，那么在修改/添加字段时更改所有代码是完全可以接受的（甚至是可取的，因为它会强制您考虑到它影响的任何地方的变化）。

2. 变量或“弱”类型是一个红旗，因为如上所述，C＃是一种强类型语言。 强类型有很多优点，其中最好的是编译时错误检查。 如果您想要处于弱类型环境中，请三思而后行。

3. 这可以追溯到通用数据。 您可以使用键入的数据模板根据类型完成某些“格式化”更改，但这是多态的（而不是弱类型）方案。 您可以使用转换器来执行您描述的货币格式，但我会考虑您要做的事情，并确保它是您想要的方向。

更新2强类型应该适合这种情况。 实际上，您正在与WCF服务进行通信，根据定义，它是强类型的（这是DataContracts的重点，如果您不这样做，请修复它并为您节省很多麻烦）。 因此，我们知道您的模型（WCF服务）具有强类型数据对象，具有“销售日期”，“客户名称”，“销售导入”，“供应商名称”和“每个客户的销售额”等属性。 现在我们只需要三个视图（甚至一个灵活视图）来完成您的三个场景。

您当然不需要三个二进制文件，即使使用三个视图方法（您只需要一种方法来选择哪个视图处于活动状态）。 您甚至可以使用应用程序配置来确定要使用的“客户端”，或者通过MEF加载您的视图。 一种灵活的视图方法需要做更多的工作，因为你必须绑定你的列集合而不是静态定义（一个问题，顺便说一句，我目前正在为我的一个项目工作）。

简而言之，有很多方法可以显示不同的视图。 我不建议根据数据更改视图，因为您的用户不会期望它，并且实现起来会非常混乱。 如果您希望“客户端1”只能访问“视图1”，我会在应用配置中设置它，或者仅分发“视图1”插件并使用MEF加载它。 如果所有客户端都能够看到所有视图，则需要使用某种组合框或导航栏。

更新3对同一视图模型（可能）具有多个视图，尤其是同一模型的多个视图模型，是使用MVVM的原因之一！ 我很高兴你能发现这个。 关于你的问题：

至于你的第一个评论：

1. 您的模型（在WCF方面）将不了解用户过滤器，除非您的请求包含它们。 包含该信息没有问题（实际上我会鼓励它降低网络利用率），但在设计服务合同时需要注意这一点。

2. 在客户端始终查看模型（我的知识无一例外）。 客户端“模型”成为场景中的WCF代理。

至于你的第二个：

1. 绝对有一种从数据库创建数据模型类的方法，事实上，我会鼓励它。 .NET有一个名为Entity Framework的库（目前版本为6.02，在Nuget上可用 ），它将使用自动外键导航和许多其他功能（ MSDN ）自动生成数据库“对象”。 一般来说，EF类不能通过WCF直接发送（由于导航属性，递归会破坏序列化程序）。 因此，您要发送给客户端的任何内容都应作为手动创建的DataContract发送，服务器上的类应在两者之间进行转换。

2. 我不知道链接，但拥有多个视图非常简单，您只需使用Content Presenter并在需要更改时设置支持UserControl属性。 它也可以通过使用制表符控件来实现，也可能是无数其他方式：

    <ContentPresenter Content="{Binding CurrentView}"/> 

3. 请参阅上面关于在WCF中使用EF类的说明。 即使您不使用EF，通常也建议使用自定义构建的数据对象作为合同。 这样，您只发送所需的信息，并且您的合同库不会与数据库/模型对象混在一起。

更新4 1.请记住，您不希望将数据库对象直接公开给WCF，尤其是您不希望对EF对象执行此操作（因为导航属性）。 所以你可以：（A）为你的DAL使用EF并转换为WCF的Data Contract对象（推荐）或（B）创建你自己的模型对象，这可能与数据契约对象相同（尽管我仍然会保留他们分开）并通过ADO.NET或类似的东西做DAL。 如果使用EF，数据库CRUD操作非常容易，如您所述。

1. 如果数据不同，您只需要不同的视图模型。 如果您的视图模型（主要）由不同视图以不同方式显示的大量对象组成，那么我认为没有理由在多个视图模型中复制代码。 经验法则是：视图模型应独立于视图。 只要您的VM中没有任何特定于视图的视图代码，就可以根据需要将其重复用于任意数量的视图。

2. 你的最后一个问题是巨大的，虽然我很乐意给你我的意见，你会发现，如果你问100个工程师这个问题，他们都会给你不同的答案（因为你似乎已经找到了）。

所以，首先，你是绝对正确的。 使用MVVM（或任何设计模式）将增加您必须编写的代码量，有时会非常显着（特别是当您刚刚启动MVVM项目时，样板代码的数量似乎非常荒谬）。

但是，设计模式的重点不是使我们的代码大小更小，而是使其更具可扩展性，可维护性和可测试性。 特定于MVVM，您可以在同一视图模型上放置多个视图（如您所见），并能够将多个视图模型放在同一模型上。 这意味着如果要添加视图或视图模型，则不必重写大量代码。 此外，视图模型和模型都很容易测试，因为他们不了解UI。

一般来说，我的优秀设计规则是使用常识！ 。 如果将来可能会更改/扩展，使用设计模式几乎总是值得额外的代码。 如果我只是想在一小时内扔掉它，谁在乎呢？

就像我说的那样，设计模式的适用性以及何时偏差都是正确的，这在软件工程中是一个巨大的争论。 我鼓励你去做有意义的事情（当然考虑未来），并在你错了时重构。

如果您有更多问题，请告诉我是否能解决您的问题。