XAML 代码隐藏文件和 MVC
代码隐藏文件是否与 MVC 的 Control 类或边界控制实体模式具有相同的用途？
我用 Silverlight 和 WPF 做了一些小项目，大多数时候我几乎把逻辑放在代码隐藏文件中。尽管参考了其他课程。并非所有内容都在后面的代码中。
代码隐藏文件的最初目的是什么？你们大多数人如何使用它？
谢谢，
格兰特
Does the code behind file have the same purpose as a Control class of MVC or the Boundary-Control-Entity Pattern?
I did some small projects with Silverlight and WPF, and most of the time I pretty much put the logic in the code behind file. Though with references to other classes. Not everything in the code behind.
What was/is the initial purpose of the code behind file and how do most of you use it?
Thanks,
Grant
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
开发 Silverlight 应用程序的首选设计模式是 MVVM，其中视图模型更接近于接管 MVC 中控制器的角色。当使用 MVVM 模式时，我只会使用控件背后的代码来实现与数据关系不大的 UI-only（仅视图）逻辑，例如执行动画和其他特殊效果。
The preferred design pattern for developing Silverlight applications is MVVM, in which the View Model is closer to taking over the role of a controller in MVC. When using the MVVM pattern, I'd only use the code behind of controls to implement UI-only (view-only) logic that has little to do with the data, such as performing animations and other special effects.
最初，代码隐藏文件与 WPF 中的数据转换器结合使用，与 VB6、C#、VB.NET 等中的代码隐藏文件具有相同的用途。它主要是放置响应 UI 事件的代码的地方。然而，对于 WPF 和 Silverlight，代码隐藏文件中的编码可能非常混乱，并且如果要实现的程序不仅仅是最简单的程序，则很容易导致以后的维护问题。
我认为“模型-视图-视图模型”(MVVM) 是在 WPF 开发后期构思的； Silverlight 的构思晚于 MVVM。据我所知，很接近。并不是每个我听到谈论 WPF 或 Silverlight 的顾问都相信 MVVM 是“首选”设计模式，但它是一个可靠的抽象模型。
即使在今天，WPF 的工具性也不如 WinForms。这是导致潜在维护问题变得非常混乱的部分原因。 MVVM 作为一种设计模式，弥补了 XAML 和 WPF/Silverlight 作为用户界面模型的不成熟所带来的许多缺陷，同时发挥了 XAML 和 WPF 提供的大部分巨大优势。
MVVM 的摘要可在此处、此处，以及此处。 Josh Smith 是该模式的权威，他出售一本名为“Advanced MVVM”的书，其中有人告诉我很有用；不过，我能够在没有它的情况下实现一些复杂的实现。
Originally, the code-behind file, in conjunction with data converters in WPF, served the same purpose as the code-behind in VB6, C#, VB.NET, what have you. It is primarily a place to put code that responds to UI events. However, in the case of WPF and Silverlight, coding in the code-behind file is potentially very messy and can easily lead to maintenance problems later on, if there is anything more than the simplest program to be implemented.
"Model-View-ViewModel" (MVVM) was conceived, I think, late in the development of WPF; Silverlight was conceived later than MVVM. Near as I can tell. Not every consultant I've heard talking about WPF or Silverlight is convinced that MVVM is "the preferred" design pattern, but it is a solid abstraction model.
WPF isn't as well tooled as WinForms, even today. This is part of what makes it potentially very messy with the potential maintenance problems. MVVM, as a design pattern, makes up for a lot of the drawbacks stemming from the immaturity of XAML and WPF/Silverlight as a user interface model, while bringing forward most of the tremendous advantages offered by XAML and WPF.
Summaries of MVVM are available here, here, and here. Josh Smith is a leading authority on the pattern, he sells a book called "Advanced MVVM" which I'm told is useful; I was able to implement some complex implementations without it, though.