What is the benefit of keeping code behind 'clean'?
保持代码“干净”的好处是什么？
Many times I come across posts here about someone trying to do the equivalent in XAML instead of code behind. Their only reason being they want to keep their code behind 'clean'. Correct me if I am wrong, but is not the case that:
很多时候，我在这里看到有关某人试图在XAML中执行等效操作而不是代码隐藏的帖子。他们唯一的理由是他们希望将代码保持在“干净”之后。如果我错了，请纠正我，但事实并非如此：
InitializeComponent();Is it purely psychological? I suspect it is developers who come from a web background and like markup as opposed to code.
这纯粹是心理上的吗？我怀疑是开发人员来自网络背景，喜欢标记而不是代码。
EDIT: I don't propose code behind instead of XAML - use both - I prefer to do my binding in XAML too - I am just against making every effort to avoid writing code behind esp in a WPF app - it should be a fusion of both to get the most out of it.
编辑：我不提出代码而不是XAML - 同时使用 - 我更喜欢在XAML中进行绑定 - 我只是反对尽力避免在WPF应用程序中编写esp背后的代码 - 它应该是融合的两者都是为了充分利用它。
6 个解决方案
#1
8
1. The designer perspective
1.设计师的观点
UIs are often built by designers using designer tools (expression blend and friends). If I have this kind of worklow, it simply just doesn't work if you put a significant amount of UI-related code in codebehind. At least that's the experience we made. The code and the behavior/functionalty it defines is inacessable to the designer:
UI通常由设计师使用设计器工具（表达混合和朋友）构建。如果我有这种工作流程，那么如果你在代码隐藏中放入大量与UI相关的代码，它就会失效。至少这是我们的经验。它定义的代码和行为/功能对于设计者来说是不可能的：
- For the most part that code is only executed at runtime and not while designing. So the designer doesn't see the full story while designing.
- 在大多数情况下，代码仅在运行时执行，而不是在设计时执行。所以设计师在设计时并没有看到完整的故事。
- Designers are not programmers and only have limited (if at all) porgramming skills so they most likely are incapable of refining the UI behavior defined there.
- 设计师不是程序员，只有有限的（如果有的话）编程技能，所以他们很可能无法改进那里定义的UI行为。
Additionally we have made the experience that it gets quite hard to find a way to provide mocked designtime data (d:DesignInstance, d:DesignData, d:DataContext) for the designer to work with if there is codebehind.
此外，我们已经获得了一种经验，即如果存在代码隐藏，设计人员可以使用这种方法很难找到提供模拟设计时数据的方法（d：DesignInstance，d：DesignData，d：DataContext）。
2. The developer perspective
2.开发人员的观点
UI-related code in codebehind (I am assuming here that it is unnecessary to talk about the odds of putting domain logic in codebehind) is code that is not reusable. It is code that is bound forever to that one specific UserControl/Window/Page. If I for example instead would write a custom attached property or a behavior I get resuablity plus I make our desginers happy because they can use it too.
代码隐藏中的UI相关代码（我在这里假设没有必要讨论将域逻辑置于代码隐藏中的可能性）是不可重用的代码。它是永远绑定到特定UserControl / Window / Page的代码。例如，如果我改为编写自定义附加属性或行为，我会获得可靠性，我会让我们的设计师感到高兴，因为他们也可以使用它。
All code I put in codebehind is code that is hard to test. Of course it mostly doesn't get easier just by putting it in XAML or in a custom attached property. But depending on what type of functionality I put in codebehind there are cases where I could have encapsulate it in testable (reusable) classes.
我在代码隐藏中放入的所有代码都是难以测试的代码。当然，通过将其置于XAML或自定义附加属性中，大多数情况下并不容易。但是根据我在代码隐藏中放置的功能类型，我可以将其封装在可测试（可重用）类中。
Defining appearance and behavior in XAML tends to be less (as opposed to the questioners argument) error prone than in code. I just can't make as many mistakes in XAML as I can in code. If I did something wrong chances are that I see it right away in the designer/visual studio. Of course the tools still can improve here. Infact if I additionally use ReSharper those "incorrect spelling" miskates in XAML that the questioner mentions are almost impossible to make. I get that code highlighted right away. I am sure the standard tools will pick this up. XAML is the preferred way to define the UI in WPF and a much higher effort has been made by microsoft to assure that it works as expected than using code. Infact I have already spent quite some time debugging memoryleaks and runtime exceptions on code that did UI related stuff and could have been moved to XAML with little or no extra effort.
在XAML中定义外观和行为往往比在代码中更容易出错（与提问者参数相反）。我不能在代码中尽可能多地在XAML中犯错。如果我做错了，我很快就会在设计师/视觉工作室看到它。当然，这里的工具仍然可以改进。事实上，如果我另外使用ReSharper，XAML中的“错误拼写”错误，提问者提到几乎是不可能的。我立即突出显示了该代码。我相信标准工具会选择它。 XAML是在WPF中定义UI的首选方式，微软已经做出了更大的努力，以确保它比使用代码更符合预期。事实上，我已经花了很长时间在代码上调试内存泄漏和运行时异常，这些代码执行与UI相关的东西，并且可以很少或不需要额外的努力就可以移动到XAML。
If I ease up on the codebehind abstinence there is a higher risk that I write clutterd and bad code. Sometimes it is just to tempting to put a quick hack in codebehind. We have sufferd from the consequences more than once.
如果我放松代码隐藏的禁欲，那么我编写混乱和错误代码的风险就更高。有时它只是诱惑快速入侵代码隐藏。我们不止一次遭受这种后果。
Using codebehind is rarely really necessary. Once you get used to ViewModel driven UIs there is alomst never a justifyable necessity for codebehind. It doesn't take much effort to put it somewhere else. So why bother?
使用代码隐藏很少是必要的。一旦习惯了ViewModel驱动的用户界面，那么代码隐藏绝对不可能是合理的必要条件。把它放在其他地方并不需要太多努力。为什么要这么麻烦？
#2
6
I think it has to do with
我认为这与它有关
- Testability - it stems from the idea of keeping the Views thin ala the ModelViewController / MVP / MVVM patterns for building GUIs. That way the view just has controls which are bound to a backing presenter class, which can then be easily tested without having to involve the GUI. You can achieve a remarkable degree of confidence just by testing via the presenters. It is significantly faster than testing via the UI too.
- 可测试性 - 它源于保持视图细化的ModelViewController / MVP / MVVM模式以构建GUI的想法。这样，视图就会拥有绑定到支持演示者类的控件，然后可以轻松测试，而无需涉及GUI。只需通过演示者进行测试，您就可以获得极高的信心。它也明显快于通过UI进行测试。
- Moving to declarative programming as compared to imperative programming - XAML is declarative programming. You don't need to test XAML markup. Also it is MS code that is more or less guaranteed to work and remain working. So you can be quite certain that initializeComponent won't break with a check-in that you just made. So theoretically, you could get by without ever testing your views - provided your code-behind has no custom/hand-written logic.
- 与命令式编程相比，转向声明性编程 - XAML是声明式编程。您不需要测试XAML标记。此外，MS代码或多或少保证可以工作并保持工作。因此，您可以确定initializeComponent不会因您刚刚签入的签入而中断。所以从理论上讲，如果您的代码隐藏没有自定义/手写逻辑，那么您可以在不测试视图的情况下完成任务。
#3
5
You should keep all your code clean, and moving the work from the code behind to the XAML is not keeping it clean it is just moving where it is located. You should put the code (and XAML is a form of code) where it makes the most sense to put it, while attempting to follow OOD Principles as best you can.
您应该保持所有代码的清洁，并将工作从后面的代码移到XAML并不是保持干净，它只是移动到它所在的位置。您应该将代码（和XAML是一种代码形式）放在最合适的位置，同时尽可能地遵循OOD原则。
#4
1
Avoiding the code-behind file should mostly be aimed at by people following MVVM. My view is this: having business logic in code behind leaves your View and ViewModel dependent on each other (directly or indirectly).
避免代码隐藏文件应主要针对跟随MVVM的人。我的观点是：在代码中使用业务逻辑会使View和ViewModel相互依赖（直接或间接）。
If you restrict code-behind logic to behavior of the view itself only, then you can interact fully with your application via the ViewModels. This also implies that if you manage somehow to put business logic in the xaml itself (not delegated back to the ViewModel), this is also wrong.
如果仅将代码隐藏逻辑限制为视图本身的行为，则可以通过ViewModel与应用程序完全交互。这也意味着如果你以某种方式管理业务逻辑在xaml本身（没有委托回ViewModel），这也是错误的。
To answer the question more directly: I see "do everything in XAML" as bind everything to your ViewModel / all business logic in the ViewModel.
更直接地回答这个问题：我看到“在XAML中做所有事情”将所有内容绑定到ViewModel中的ViewModel /所有业务逻辑。
#5
0
I think the reason why most programmers (especially those who practices MVVM) don't put in code in code-behind files is to utilize data binding in XAML, which is I think is a lot simpler than doing it programmatically. Also, maybe it is easier for developers and designers to work together using XAML (e.g. fill up with design-time data).
我认为大多数程序员（特别是那些实践MVVM的人）没有在代码隐藏文件中加入代码的原因是为了利用XAML中的数据绑定，我认为这比编程方式简单得多。此外，开发人员和设计人员可能更容易使用XAML协同工作（例如，填写设计时数据）。
#6
-1
WPF and XAML for me is broken. Too many dynamic elements, which are checkable during runtime -- that's very bad. So use XAML all UI I know during design stage -- if the text is bold or not, wiring data, setting converters, validators, and so on.
WPF和XAML对我来说很糟糕。动态元素太多，在运行时可以检查 - 这非常糟糕。因此，在设计阶段使用XAML我知道的所有UI - 如果文本是否为粗体，则连接数据，设置转换器，验证器等。
I don't know what exactly you mean by clean code. If it is clean, I use clean code, if not -- I don't, and I don't care anyway, it seems more logical for me.
我不知道干净代码究竟是什么意思。如果它是干净的，我会使用干净的代码，如果不是 - 我没有，我也不在乎，对我来说似乎更合乎逻辑。
#1
8
1. The designer perspective
1.设计师的观点
UIs are often built by designers using designer tools (expression blend and friends). If I have this kind of worklow, it simply just doesn't work if you put a significant amount of UI-related code in codebehind. At least that's the experience we made. The code and the behavior/functionalty it defines is inacessable to the designer:
UI通常由设计师使用设计器工具（表达混合和朋友）构建。如果我有这种工作流程，那么如果你在代码隐藏中放入大量与UI相关的代码，它就会失效。至少这是我们的经验。它定义的代码和行为/功能对于设计者来说是不可能的：
- For the most part that code is only executed at runtime and not while designing. So the designer doesn't see the full story while designing.
- 在大多数情况下，代码仅在运行时执行，而不是在设计时执行。所以设计师在设计时并没有看到完整的故事。
- Designers are not programmers and only have limited (if at all) porgramming skills so they most likely are incapable of refining the UI behavior defined there.
- 设计师不是程序员，只有有限的（如果有的话）编程技能，所以他们很可能无法改进那里定义的UI行为。
Additionally we have made the experience that it gets quite hard to find a way to provide mocked designtime data (d:DesignInstance, d:DesignData, d:DataContext) for the designer to work with if there is codebehind.
此外，我们已经获得了一种经验，即如果存在代码隐藏，设计人员可以使用这种方法很难找到提供模拟设计时数据的方法（d：DesignInstance，d：DesignData，d：DataContext）。
2. The developer perspective
2.开发人员的观点
UI-related code in codebehind (I am assuming here that it is unnecessary to talk about the odds of putting domain logic in codebehind) is code that is not reusable. It is code that is bound forever to that one specific UserControl/Window/Page. If I for example instead would write a custom attached property or a behavior I get resuablity plus I make our desginers happy because they can use it too.
代码隐藏中的UI相关代码（我在这里假设没有必要讨论将域逻辑置于代码隐藏中的可能性）是不可重用的代码。它是永远绑定到特定UserControl / Window / Page的代码。例如，如果我改为编写自定义附加属性或行为，我会获得可靠性，我会让我们的设计师感到高兴，因为他们也可以使用它。
All code I put in codebehind is code that is hard to test. Of course it mostly doesn't get easier just by putting it in XAML or in a custom attached property. But depending on what type of functionality I put in codebehind there are cases where I could have encapsulate it in testable (reusable) classes.
我在代码隐藏中放入的所有代码都是难以测试的代码。当然，通过将其置于XAML或自定义附加属性中，大多数情况下并不容易。但是根据我在代码隐藏中放置的功能类型，我可以将其封装在可测试（可重用）类中。
Defining appearance and behavior in XAML tends to be less (as opposed to the questioners argument) error prone than in code. I just can't make as many mistakes in XAML as I can in code. If I did something wrong chances are that I see it right away in the designer/visual studio. Of course the tools still can improve here. Infact if I additionally use ReSharper those "incorrect spelling" miskates in XAML that the questioner mentions are almost impossible to make. I get that code highlighted right away. I am sure the standard tools will pick this up. XAML is the preferred way to define the UI in WPF and a much higher effort has been made by microsoft to assure that it works as expected than using code. Infact I have already spent quite some time debugging memoryleaks and runtime exceptions on code that did UI related stuff and could have been moved to XAML with little or no extra effort.
在XAML中定义外观和行为往往比在代码中更容易出错（与提问者参数相反）。我不能在代码中尽可能多地在XAML中犯错。如果我做错了，我很快就会在设计师/视觉工作室看到它。当然，这里的工具仍然可以改进。事实上，如果我另外使用ReSharper，XAML中的“错误拼写”错误，提问者提到几乎是不可能的。我立即突出显示了该代码。我相信标准工具会选择它。 XAML是在WPF中定义UI的首选方式，微软已经做出了更大的努力，以确保它比使用代码更符合预期。事实上，我已经花了很长时间在代码上调试内存泄漏和运行时异常，这些代码执行与UI相关的东西，并且可以很少或不需要额外的努力就可以移动到XAML。
If I ease up on the codebehind abstinence there is a higher risk that I write clutterd and bad code. Sometimes it is just to tempting to put a quick hack in codebehind. We have sufferd from the consequences more than once.
如果我放松代码隐藏的禁欲，那么我编写混乱和错误代码的风险就更高。有时它只是诱惑快速入侵代码隐藏。我们不止一次遭受这种后果。
Using codebehind is rarely really necessary. Once you get used to ViewModel driven UIs there is alomst never a justifyable necessity for codebehind. It doesn't take much effort to put it somewhere else. So why bother?
使用代码隐藏很少是必要的。一旦习惯了ViewModel驱动的用户界面，那么代码隐藏绝对不可能是合理的必要条件。把它放在其他地方并不需要太多努力。为什么要这么麻烦？
#2
6
I think it has to do with
我认为这与它有关
- Testability - it stems from the idea of keeping the Views thin ala the ModelViewController / MVP / MVVM patterns for building GUIs. That way the view just has controls which are bound to a backing presenter class, which can then be easily tested without having to involve the GUI. You can achieve a remarkable degree of confidence just by testing via the presenters. It is significantly faster than testing via the UI too.
- 可测试性 - 它源于保持视图细化的ModelViewController / MVP / MVVM模式以构建GUI的想法。这样，视图就会拥有绑定到支持演示者类的控件，然后可以轻松测试，而无需涉及GUI。只需通过演示者进行测试，您就可以获得极高的信心。它也明显快于通过UI进行测试。
- Moving to declarative programming as compared to imperative programming - XAML is declarative programming. You don't need to test XAML markup. Also it is MS code that is more or less guaranteed to work and remain working. So you can be quite certain that initializeComponent won't break with a check-in that you just made. So theoretically, you could get by without ever testing your views - provided your code-behind has no custom/hand-written logic.
- 与命令式编程相比，转向声明性编程 - XAML是声明式编程。您不需要测试XAML标记。此外，MS代码或多或少保证可以工作并保持工作。因此，您可以确定initializeComponent不会因您刚刚签入的签入而中断。所以从理论上讲，如果您的代码隐藏没有自定义/手写逻辑，那么您可以在不测试视图的情况下完成任务。
#3
5
You should keep all your code clean, and moving the work from the code behind to the XAML is not keeping it clean it is just moving where it is located. You should put the code (and XAML is a form of code) where it makes the most sense to put it, while attempting to follow OOD Principles as best you can.
您应该保持所有代码的清洁，并将工作从后面的代码移到XAML并不是保持干净，它只是移动到它所在的位置。您应该将代码（和XAML是一种代码形式）放在最合适的位置，同时尽可能地遵循OOD原则。
#4
1
Avoiding the code-behind file should mostly be aimed at by people following MVVM. My view is this: having business logic in code behind leaves your View and ViewModel dependent on each other (directly or indirectly).
避免代码隐藏文件应主要针对跟随MVVM的人。我的观点是：在代码中使用业务逻辑会使View和ViewModel相互依赖（直接或间接）。
If you restrict code-behind logic to behavior of the view itself only, then you can interact fully with your application via the ViewModels. This also implies that if you manage somehow to put business logic in the xaml itself (not delegated back to the ViewModel), this is also wrong.
如果仅将代码隐藏逻辑限制为视图本身的行为，则可以通过ViewModel与应用程序完全交互。这也意味着如果你以某种方式管理业务逻辑在xaml本身（没有委托回ViewModel），这也是错误的。
To answer the question more directly: I see "do everything in XAML" as bind everything to your ViewModel / all business logic in the ViewModel.
更直接地回答这个问题：我看到“在XAML中做所有事情”将所有内容绑定到ViewModel中的ViewModel /所有业务逻辑。
#5
0
I think the reason why most programmers (especially those who practices MVVM) don't put in code in code-behind files is to utilize data binding in XAML, which is I think is a lot simpler than doing it programmatically. Also, maybe it is easier for developers and designers to work together using XAML (e.g. fill up with design-time data).
我认为大多数程序员（特别是那些实践MVVM的人）没有在代码隐藏文件中加入代码的原因是为了利用XAML中的数据绑定，我认为这比编程方式简单得多。此外，开发人员和设计人员可能更容易使用XAML协同工作（例如，填写设计时数据）。
#6
-1
WPF and XAML for me is broken. Too many dynamic elements, which are checkable during runtime -- that's very bad. So use XAML all UI I know during design stage -- if the text is bold or not, wiring data, setting converters, validators, and so on.
WPF和XAML对我来说很糟糕。动态元素太多，在运行时可以检查 - 这非常糟糕。因此，在设计阶段使用XAML我知道的所有UI - 如果文本是否为粗体，则连接数据，设置转换器，验证器等。
I don't know what exactly you mean by clean code. If it is clean, I use clean code, if not -- I don't, and I don't care anyway, it seems more logical for me.
我不知道干净代码究竟是什么意思。如果它是干净的，我会使用干净的代码，如果不是 - 我没有，我也不在乎，对我来说似乎更合乎逻辑。