ContentDialog是UWP开发中最常用的组件之一，一个体验良好的UWP应用很难避免不去使用它。博客园里也有许多的文章介绍如何来利用ContentDialog实现各种自定义样式的弹窗界面。不过实际上ContentDialog是一个令人又爱又恨的组件，今天我们就来说一下ContentDialog的缺点。
ContentDialog适合实现轻量级的UI需求，但在处理复杂UI需求时非常难用，例如说：
- 多层级弹窗情况下的UI实现;
- MVVM框架下的UI与业务逻辑的分离；
- 需要弹窗关闭时返回用户操作结果的情况。
上述情况下，如果仍旧使用ContentDialog实现功能需求，会需要很多的代码来完成界面UI交互，这是多余且没有必要的。
多层级弹窗情况下的UI实现;
先说第一种情况，多层级弹窗情况下的UI实现。假设我们有一个这样的需求：我们需要弹出一个窗口让用户修改应用设置，同是在用户修改后点击“保存设置”按钮时，弹出一个自定义UI的确认对话框询问用户是否确定保存。
怎么实现呢？很自然的想到，我们可以写两个ContentDialog，一个是设置界面的弹窗，另外一个是自定义UI的确认对话框。先弹出设置弹窗，点击“保存设置”是弹出确认对话框。听起来很完美，逻辑上也没有问题，编码运行一下呢，应用崩溃了...
这是个悲剧，看下VS的崩溃信息：
Only a single ContentDialog can be open at any time.
WTF!!! UWP应用同时只支持唤出一个ContentDialog 么？这也太坑了吧！
不要惊讶，事实上确实如此，关于这点，微软官方给出的解决方案是这样的：
ContentDialog的内部实现其实是依赖Popup，这就让我有了一个大胆的想法，我们程序员最爱干的事情是什么？造轮子呀！ContentDialog不好用，造个好用的新轮子呀！
接下来几篇博文来教大家如何造一个好用的，适用于MVVM框架的弹窗层组件。有兴趣的可以先看一下我的开源项目HHChaosToolkit中的Picker部分（GitHub链接点这里）。
好的，本篇博文到此结束，不知道大家有没有收获，谢谢大家！
