A B Asked:2022-01-09 06:32:37 +0000 UTC2022-01-09 06:32:37 +0000 UTC 2022-01-09 06:32:37 +0000 UTC 在 WPF 应用程序中使用什么更好：Page-Frame 或 ContentPresenter 772 我正在 UserControl-ContentPresenter 包中制作页面界面。使用 Page-Frame，使用 UserControl-ContentPresenter 一切都很好。但我多次听说最好使用第二种选择。谁是对的？ 这些哪个更好用？ c# 1 个回答 Voted Best Answer EvgeniyZ 2022-01-09T07:45:30Z2022-01-09T07:45:30Z 简而言之，它们Page严重违反了 MVVM 方法，因为这是一个视图层，不应该对其他层负责。如果你的项目不使用 MVVM，你只想让它工作，不考虑性能，那么你可以使用页面。但是，如果您希望它符合预期，具有绑定和所有其他 WPF 功能，那么您应该考虑 MVVM 方法，这最终会导致拒绝使用Page并切换到UserControlc ContentPresenter，因为在它们的帮助下，您可以轻松地将 UI 与主要逻辑。 也值得阅读这里的文档并了解例如Page可以做什么，我们将在那里看到以下内容： 封装可由 Windows Internet Explorer、NavigationWindow 和 Frame 托管的可导航内容页面。 如您所见，页面可以做很多事情，但大多数事情在许多项目中根本无用。在这里值得问自己一个问题：我是否需要一些我不会充分利用的东西？ 如果再深入一点，那么…… 看，WPF中基本上有两种设计方法： 我们只是说，基本的一个是当您编写一个项目并且不考虑myTextBox.Text = "Привер мир!"在您的代码中使用控件（很多新手都是这样的吧？只有这种方法有许多非常重要的问题： 可扩展性。当您在一个地方同时使用 UI 和基础时，添加或更改某些内容可能会非常有问题。 表现。当您直接拖拽 UI 元素并且不分离核心逻辑时，您的应用程序会花费更多精力来完成手头的任务。 这种方法违反了所有类型的 OOP 和 SOLID 方法，因为同样，您将所有内容都混淆了，而不是使用数据，而是开始使用 UI。 MVVM——这种方法的本质在于，整个项目被划分为松散连接的层（Model/ViewModel/View），并借助绑定等机制，WPF本身为我们做了一些工作，我们只是需要指定必要的数据和所需的显示。数据本身的开发方式使得我们根本不知道我们有一个 UI，就好像我们有一个必须执行给定逻辑的控制台项目一样。也就是说，在这样一个项目中，我们有： 模型 - 负责数据（处理数据库、站点、文件等），他不知道数据将在哪里使用、由谁以及何时使用，他的任务只是执行他的逻辑并给我们一个控制“接口”，我们将通过它在代码中发送和接收数据。 View 是项目界面（UI）。这一层也根本不知道任何人的存在，它只知道它TextBox必须有这样那样的风格，并且必须从某人那里获取文本{Binding T}，其中T一些可能根本不存在的抽象名称。也就是在View层，只做应用的设计，不做逻辑。 ViewModel - 与模型通信并为视图层实现相同的“抽象名称”（属性）的层。该层也不知道 View 层，不知道应用程序的 UI 是什么，它只提供数据并与 Model 通信，仅此而已。 如您所见，在 MVVM 方法中，所有内容都被分解成小块，一些模块彼此并不真正了解，而不是myTextBox.Text = "Привет мир!"，它只是简单地使用Text = "Привет мир!"，其中Text是一个单独类的某个属性，一个类负责其具体职责。因此，我们的项目有很多优点： 可扩展性。我们可以轻松更改、添加、删除任何逻辑，并且在大多数情况下，这不需要更改其他层（日期或 UI）。并且如果我们也连接 IoC 的方式，那么我们项目的模块化可以大大增加，而不是开发一个项目，我们最终将开发单独的子程序，这将更容易调试和更容易设计。 表现。由于我们不会经常对不必要的数据进行操作，因此我们有纯类，只做需要的事情（而不是在其他人之后计算），我们在应用程序的速度上获胜。此外，由于绑定和其他“魔法”，WPF 本身为我们做了很多事情（绘制界面、处理事件等等）。 遵守其他基本规则（OOP、SOLID）。MVVM 方法完美地补充了所有这些规则，我们可以轻松地做出各种“单一职责”、“开放/封闭”等。 如您所见，完全有两种不同的方法和设计风格，第一种允许一切，但不要说您很难支持项目并实现所需的功能。而第二种方式则要求你遵守规则，这样以后会大大节省你的神经和体力。在这里我们立即看到，在 MVVM 中，我们不能在代码中使用 UI，这是最公然违反其基本规则的行为，正因为如此，我们不能如此轻松地使用它Page，尤其是Frame，因为我们必须绑定它类型为 content 的属性Page，这是 View 层。结果，我们得到虚拟机知道视图。 一般来说，编程是每个人都有自己的事情。用你的头脑思考什么更好，如何最好，为自己学习，尝试两种方法，比较，然后才选择如何最好地在你的任务中具体行动。所有设计规则和方法都是为了让生活更轻松，但这并不意味着必须 100% 遵守。
简而言之，它们
Page严重违反了 MVVM 方法，因为这是一个视图层，不应该对其他层负责。如果你的项目不使用 MVVM，你只想让它工作，不考虑性能，那么你可以使用页面。但是，如果您希望它符合预期，具有绑定和所有其他 WPF 功能，那么您应该考虑 MVVM 方法，这最终会导致拒绝使用Page并切换到UserControlcContentPresenter，因为在它们的帮助下，您可以轻松地将 UI 与主要逻辑。也值得阅读这里的文档并了解例如Page可以做什么，我们将在那里看到以下内容：
如您所见，页面可以做很多事情，但大多数事情在许多项目中根本无用。在这里值得问自己一个问题：我是否需要一些我不会充分利用的东西？
如果再深入一点，那么……
看，WPF中基本上有两种设计方法：
我们只是说，基本的一个是当您编写一个项目并且不考虑
myTextBox.Text = "Привер мир!"在您的代码中使用控件（很多新手都是这样的吧？只有这种方法有许多非常重要的问题：MVVM——这种方法的本质在于，整个项目被划分为松散连接的层（Model/ViewModel/View），并借助绑定等机制，WPF本身为我们做了一些工作，我们只是需要指定必要的数据和所需的显示。数据本身的开发方式使得我们根本不知道我们有一个 UI，就好像我们有一个必须执行给定逻辑的控制台项目一样。也就是说，在这样一个项目中，我们有：
模型 - 负责数据（处理数据库、站点、文件等），他不知道数据将在哪里使用、由谁以及何时使用，他的任务只是执行他的逻辑并给我们一个控制“接口”，我们将通过它在代码中发送和接收数据。
View 是项目界面（UI）。这一层也根本不知道任何人的存在，它只知道它
TextBox必须有这样那样的风格，并且必须从某人那里获取文本{Binding T}，其中T一些可能根本不存在的抽象名称。也就是在View层，只做应用的设计，不做逻辑。ViewModel - 与模型通信并为视图层实现相同的“抽象名称”（属性）的层。该层也不知道 View 层，不知道应用程序的 UI 是什么，它只提供数据并与 Model 通信，仅此而已。
如您所见，在 MVVM 方法中，所有内容都被分解成小块，一些模块彼此并不真正了解，而不是
myTextBox.Text = "Привет мир!"，它只是简单地使用Text = "Привет мир!"，其中Text是一个单独类的某个属性，一个类负责其具体职责。因此，我们的项目有很多优点：如您所见，完全有两种不同的方法和设计风格，第一种允许一切，但不要说您很难支持项目并实现所需的功能。而第二种方式则要求你遵守规则，这样以后会大大节省你的神经和体力。在这里我们立即看到，在 MVVM 中，我们不能在代码中使用 UI，这是最公然违反其基本规则的行为，正因为如此，我们不能如此轻松地使用它
Page，尤其是Frame，因为我们必须绑定它类型为 content 的属性Page，这是 View 层。结果，我们得到虚拟机知道视图。一般来说，编程是每个人都有自己的事情。用你的头脑思考什么更好，如何最好，为自己学习，尝试两种方法，比较，然后才选择如何最好地在你的任务中具体行动。所有设计规则和方法都是为了让生活更轻松，但这并不意味着必须 100% 遵守。