做美妆网站名称,石家庄建设信息网必须交费吗,品牌广告语经典100条,wordpress不能置顶适用于WPF的设计模式
讨论“XAML能不能写逻辑代码”这个问题。我发现这是个有歧义的问题。这个问题可以有两种意思#xff1a; XAML能不能用来写逻辑代码#xff1f; XAML文件里能不能包含逻辑代码#xff1f; 对于第一种意思——XAML是一种声明性语言#xff0c;就是用来…适用于WPF的设计模式
讨论“XAML能不能写逻辑代码”这个问题。我发现这是个有歧义的问题。这个问题可以有两种意思 XAML能不能用来写逻辑代码 XAML文件里能不能包含逻辑代码 对于第一种意思——XAML是一种声明性语言就是用来声明UI元素的不能用来写逻辑代码 对于第二种意思——XAML文件中可以使用x:Code标签来嵌入一些C#或VB写的逻辑代码也就是把code-behind的代码挪到了XAML文件里。但请注意逻辑代码仍然是用C#或VB写的即与上面一种解释不冲突。
第二件也是聊天的时候想到的。 以前很少关注程序员们应该读什么样的书昨天和我一位已经移民澳洲的朋友吃饭提到中国学生和欧美学生的差距在这位朋友看来中国学生的专业知识要比欧美的学生强但基础知识偏弱。表象就是中国学生就业起点高但被人数太多给抵销掉了但后期积累速度慢。 基础知识弱的具体一个表现就是中国学生的母语写作能力平均水平比较低我想这也包括我在内——是不是因为忙着学外语搞的就不得而知了。 平时在我面试的时候也能感受到这一点但重点能感觉到学生的哲学和逻辑方面缺少必要的积累尽管我积累的也不多。所以最后与草小弟达成共识——程序员应该多读一些图书馆里的A类可不是Adult的A哦和B类书籍。
2. XAML有哪些优点
前面一节已经向我们透露了XAML的几个优点 • XAML可以设计出专业的UI和动画——好用 • XAML不需要专业的编程知识它简单易懂、结构清晰——易学 • XAML使设计师能直接参与软件开发随时沟通、无需二次转化——高效 然而XAML这位翩翩君子的才华可远不止这些。 自 从应用程序从命令行界面Console User InterfaceCUI这本书的读者还有用过DOS的吗就是那东西升级为图形用户界面Graphic User InterfaceGUI后程序员们就一直追求将视图View也就是UI与逻辑代码的分离。以往的开发模式中程序员很难保证用来实现UI的 代码完全不与用来实现程序逻辑的代码纠缠在一起。UI代码与逻辑代码纠缠在一起称为UI与逻辑的紧耦合它往往带来以下的后果 • 无论是软件的功能还是UI设计有所变化或者是出了bug都将导致大量代码的修改。 • 会让逻辑代码更加难以理解——修改往往比重写更困难因为在修改之前必须先读懂。 • 重用逻辑代码变成了Mission Impossible XAML 另一个巨大的优点就是它帮助开发团队真正实现了UI与逻辑的剥离。 XAML是一种单纯的声明型语言也就是说它只能用来声明一些UI元素、绘制UI和 动画在XAML里实现动画是不需要编程的根本无法在其中加入程序逻辑这就强制地把逻辑代码从UI代码中赶走了。这样与UI相关的元素统统集中在 程序的UI层、与逻辑相关的代码统统集中在程序逻辑层形成了一种“高内聚-低耦合”的结构。形成这种结构后无论是对UI进行较大改动还是打算重用底层 逻辑都不会花费太大力气。这就好比有一天你给A客户做了一个橘子A客户很喜欢A客户把你的产品介绍给了B客户B客户很喜欢橘子味道但希望它看上 去像个香蕉——这时候你只需要把橘子皮撕下来 、换一套香蕉皮即可——只需很少的成本就可以获得与先前一样大的收益。对于软件的“换肤”行为WPF提供了丰富的Template功能将在后面详 述。
小序 当梦想突然有一天变成现实的时候我们会有什么样的感觉惊喜自然是少不了的。惊喜过后呢剩下的就是要接受现实了——就像小鬼当家里的小家伙。
正文 有朝一日能把软件的UI设计和逻辑设计分开这是多年来程序开发人员的梦想。如今这个梦想被XAMLC#实现了大家都很开心。开心过后问题来了——Binding与依赖属性再好使、路由事件和命令再灵活如果不加约束地乱用和过度使用一样会导致软件架构的不稳固以及招致维护、测试和调试方面的麻烦。
那么怎样才能用好WPF带来的结构上的新特性呢我们需要做的不是从头开始创造一个新模式而是需要把WPF的新特性揉合进现有的、成熟的开发框架中去。下面让我们开始WPF开发框架的演进之旅
MVC时代 现有的开发框架林林总总但万变不离其宗这个“宗”指的就是最为经典的MVC模式。插一句有一次面试一位候选人当我问及这个模式的时候这位兄台干脆地回答到“MCV”于是我就让他“展开”讲讲了:p
MVC框架出现的年代比较早生成软件UI和逻辑用的是同一种语言比如C/Java/Delphi灵活性基本上是局限在对于同一块数据由Model暴露出来使用不同的视图View也就是UI展现给用户。
MVP时代 随着互联网的发展程序不再是一个个只能跑在特定操作系统上的代码块成千上万的用户希望使用相同的程序共享相同的数据。操作系统平台一时半会是统一不起来了A厂商程序跨到B厂商平台上的那只脚也往往被B厂商穿上一只小鞋。万般无奈下开发人员只好诉诸于所有操作系统平台的交集——浏览器——赶鸭子上驾般地做起了程序的宿主HTML也没被放过本来用于简单呈现页面的标签语言却被CSS、JavaScript、XML等等武装到了牙齿。
Anyway程序可以跑在浏览器里了需要开发人员重新把程序开发一遍吗人们发现无论程序的前端UI部分跑在哪里它的后台逻辑是不会改变的。于是人们开始想我怎样才能把UI和逻辑解耦并对逻辑层加以复用呢必需要在设计或者重构的时候考虑上这一点才可以。 于是在MVC的基础上人们向前推进了一步——MVP模式诞生了有玩儿文字游戏的嫌疑哦。Interface这个词被译成“接口”之后就丢了些原本的意思。如果还把当译成“界面”那么这个意思就能找回来了——现实世界也是这样当物体受到接力的时候凡是有界面的地方就是最容易被撕下来的地方。因此interface这个词在译成中文时“接口”传达的是其可以作为公共约束契约的一层意思“界面”则能传达解耦的一层意思。 在MVP模式中为了让UI层能够从逻辑层上“撕”下来设计师们在UI层与逻辑层之间加了一层interface。无论是UI开发人员还是数据开发人员都要尊重这个契约、按照它进行设计和开发。这样理想状态下无论是Web UI还是Window UI就都可以使用同一套数据逻辑了。
MVVM时代
现在WPF来了它带来了3D、动画、音频视频……这导致了UI的变化将更加细节化、可定制化。同时在技术层面WPF也带来了诸如Binding、Dependency Property、Routed Events、Command、DataTemplate、ControlTemplate等新特性。我们怎样才能立足于原有MVP框架、把WPF的新特性揉合进去以应对客户复杂的需求呢
图说MVP与MVVM
MVC模式大都已经非常熟悉了咱就不说了。让我们看看它的升级版——MVP
从这张图上我们可以看出如下几点
IView这个interface层帮助我们把各类UI与逻辑层解耦IView这层同时也为自动化测试提供了入口从UI层进入自动化测试太麻烦了传统的、由WinForm/Web Form/MFC等编写的UI是通过事件本质是Windows 消息与IView层沟通的。WPF与IView层的沟通最佳的手段是使用Binding当然也可以使用事件Presenter层要实现IView多态机制可以保证运行时UI层显示恰当的数据。比如Binding在程序中你可能看到Binding的Source是某个interface类型的变量——实际上这个interface变量引用着的对象才是真正的数据源可有可无的Control……有的话就当是留个纪念吧原版的MVP图里是没有Control的Control被Presenter取代这里的Presenter有点歧义之虞就我个人而言感觉Presenter是UI里的东西。
我们再来看MVVM
同样有几点注意
当我们只关注MVP模式与WPF结合的应用方式时MVP就变成了MVVM。借鉴MVP的IView层养成习惯。原版MVVM图里是没有这层的但我会在程序里加上这层。View Model听起来比Presenter要贴切得多我会把一些跟事件、命令相关的东西放在Controler里
