案例总结
通过上面的案例，我们主要认识到：如果不需要强大的图形和显示效果，WinForms和WPF 都能完成同一个需求，只是WinForms在设计的时候比较痛苦一些，并且没有单独把UI分立出来，所以很多时候都会和逻辑进行耦合;而WPF就不一样了，它用XAML来进行UI的设计，然后用后台C#或VB等语言来进行操作，这样就使职责进行了分立，使每个部分都发挥到了最好，同时也提高了开发效率。
对于长期从事WinForms或者其他没有从事过ASP.NET等开发人员, 可能不太习惯XAML的这种开发习惯. 但对于ASP.NET 的开发者来说上手就比较容易一些了，因为在很多方面它和HTML有很多相似之处. 不过也没有关系，只要做了一段时间以后就会发现XAML代码是那么的有趣，以至于看到它就有一种亲切感!
这个案例并不是介绍我们如何放弃WinForm和如何转向于WPF,只是想通过他们的异同进行一下简单的对比，大家都知道WPF的特长在于UI和逻辑的分离、强大的动画和图形效果，但是性能却是一个摆脱不去的瓶颈。而WinForm正好相反，它在性能上得到了比较好的体现，但在显示强大动画和图形效果以及一些高交互的效果方面就显得不能为力了，所以我们在做项目的时候应该有一个权衡，尤其是在现在的硬件和软件基础上。
漫谈WPF开发
谈到WPF的开发，就不能不说到MVVM，一说到MVVM，就会提及MVC、MVP等概念，那么这样一关联下来就会产生很多概念，到最后就很容易变成以概念来阐述概念，最终的结果可想而知，大家可能会一头雾水、不知所云，所以我用“漫谈WPF开发”这个小标题来阐述一下我对WPF开发的理解，当然只是自己对这些技术的总结和经验，错误之处在所难免，也希望大家能够谅解!
从2007年接触WPF和Silverlight以来，也做过一些项目了，对他们也有一些自己的理解，当然在开发这些项目的过程中也在使用其他的一些技术做项目，比如WinForm、ASP.NET(ASP.NET MVC一个项目没做完就被终止)等等，感觉不论是采用什么技术，最基本的东西都不会变，比如对数据库和文件的访问、对日志和异常的处理、对报表的展现、对打印的实现、对性能的提升、对用户的友好等等。
那么这些项目也为我们积累了不少经验，有技术上的也有其他方面的：
· 为了应付项目需求的不断变化和项目的可扩展性，我们也会引入OO和设计模式;
· 为了解除各模块和组件的耦合，我们也会利用IOC的思想解耦;
· 为了让逻辑代码清晰且没有其他代码的干扰，我们也会采用AOP的方式进行代码重组;
· 为了使项目的开发速度更快且更方便，我们也会引入ORM思想来加快项目的开发速度和可维护性;
· 为了更好组织各层开发，隔开耦合，我们也会采用MVC、MVP、MVVM模式;
· 为了提升用户的响应速度，我们会采用AJAX的方式来实现;
· 为了降低系统的负载同时提高用户的响应能力，我们也会采用MSMQ或者SSB来组织消息队列;
· 为了规范各系统的接口，提供一个统一的交互平台，我们也会采用SOA;
· 为了降低服务器的负担和提高速度，我们也会自己写一套缓存;
· 为了把产品做好，我们也会不断优化技术;
· 为了能做好外包项目，我们会不需要任何高深技术;
· 为了能得到客户满意老板好评，我们也会学会如何交流;
其实归根到底就是要分清关系，理清思绪，既要处理好与机器的关系，也要处理好与人的关系，只有这样才能把产品或者项目做成功，我也在不断学习当中，所以如果大家有一些这方面的问题和建议，我们也可以互相讨论。
前面不知所云的漫谈了一通，那么我们到底该怎么认识WPF项目的开发呢?我个人的观点是和其他技术一样，假如这是一个比较小的而且需求改动很小的项目，那么我不建议用一些高深的技术，因为它要的是马上看到效果和时间上的优势，所以应该抛弃我们的技术思想。当遇到一个比较大型的项目而且需求可能变动很大，那我们得慎重考虑系统的构架了，因为很多时候我们都会发现我们的系统无法再扩展了，这就是一个很大的“杯具”了。那么作为一个项目，我们怎样才能在事前做好呢?我觉得有以下几个方面：
· 项目情况把握：首先我们要分析项目的背景、项目的目的、项目的前景、项目的需求、项目的客户、项目的实现难度、项目的规模、项目所使用的技术、项目的最终效果等因素，只有把握好了这些方面以后，我们才能做到对项目知根知底且游刃有余。
· 项目团队把握：首先分析一下自己的团队成员组成结构，有没有领域分析人员?有几个架构师?有没有Team Leader? 有几个senor developer?有几个developer?有没有测试人员? 有没有项目配置管理员?有没有QA以及有没有类似的项目经验等。知道这些可以合理安排任务，这正是对自己团队的把握。
· 开发模式把握：不论你是开发产品还是做项目，我们都需要采取一种适合的模式，那么什么叫适合呢?这个没有准确的答案，只有根据具体情况具体分析了，如果需求比较明确且系统较大，那我们就可以用传统的瀑布模型进行开发，只要客户能接受同时自己做好各方面的监控，应该问题不大;如果需求不是很明确且周期很长，我们可以用迭代的方式进行开发，这样客户也能更加明确自己的需求同时也能看到自己想要的效果。当然如果需求不明确而且有很多不确定因素，我们也可以采用TDD的方式进行开发，如果把握得好，这样慢慢也会形成一个比较好的项目。
· 开发规范把握：作为一个多人开发的团队，没有一些规范是不行的，团队管理规范、项目管理规范、代码书写规范、开发流程规范、测试规范等等，这些都是要在开发之前定好，否则我们将会看到项目到处一盘散沙，无从管理。
· 其他方面规范：其他方面的规范就很多了，比如开发环境的规范、测试的规范、文档的规范、部署的规范等等，这个可以根据具体项目进行裁剪。
前面谈到了一些项目管理整体把握，总结就是大道至简、适可而止!那么我们如何才能在具体项目中引用一些其他技术呢?感觉思绪有点乱了，还是就此打住，等到了讲WPF具体项目或者具体技术的时候再讲，不然就真的一发不可收拾了。
