关于Oxite的教训
必须得坦率的面对，这不是一个好的案例，而是一个好的教训。
事情得从12月5日Platform D&E (developer evangelists) 部门下面的MIX Online团队将他们自己开发并正在使用的内容管理引擎项目Oxite的源码发布到社区开始说起。现在的官方简介是：
Oxite (alpha) is an open source, standards compliant, and extensible content management sample that can run anything from blogs to big web sites. We know this because it runs MIX Online.
作为目前还没有正式推出的ASP.net MVC的又一个开源项目，这本来是个好消息，社区的反应一开始也很热烈很正面，但和微软发布的其它示例不同，社区接触Oxite不久质疑的声音开始出现了。Oxite的简介暗示了Oxite可以被作为ASP.net MVC的官方范例而在社区推广，但Oxite的设计质量却可诟病处不少，这是一个可以借鉴的good example吗？
社区里的公开反馈其中以Rob Conery的分析意见最为透彻。这位仁兄是受Ruby on Rails框架的Active Record模式启发的SubSonic项目的创建者，以其对MVC模式的深刻理解而被招揽到ASP团队中促进ASP.net MVC的开发，Rob Conery现在自己也个人维护着一个ASP.net MVC的示例项目StoreFront。
Rob Conery认为：
- Oxite最关键的缺陷是跨站点脚本攻击（XSS）漏洞。基于ASP.net MVC设计上与Web Form的区别，在这点上ASP.net MVC开发时本来要做的工作就要多得多。
- 基于Repository模式的数据存取层使用provider模式实现，但却刻意地注释掉了Singleton模式的代码，这一点让人非常疑惑而且做法并不高明。
- Oxite将Controller与View分开放在不同的项目下，类似于分层架构设计中的业务逻辑层与呈现逻辑层的分离，这直接导致Controller的代码实现变得累赘。这恰因为Controller并不仅仅处理业务逻辑，而Oxite设计上对此理解有了偏差。
- Oxite中Controller的实现耦合度较高，一个名为AdminController的对象几乎包办了一切。
- 滥用ViewData，违反了MVC模式的精髓就在于保持Controller与View的轻快，易于测试这一原则。
- 对辅助组件实现的不当设计。Script/CSS这类与View实现相关的输出放在了Control实现中管理。
- 对View实现的处理不完善，比如上面提到的XSS漏洞。
I think one important thing to note is that Oxite serves as a good example of viewing an MVC implementation from a "WebForms state of mind".
除了Oxite架构设计上的不足外，Rob Conery还提到了一个观点，说起来这属于公共关系的处理领域了，作为Microsoft雇员或团队，当对外部公开谈论某些事情的时候，公众不会认为这是一个独立个体的声音，他们会认为“微软开始。。。”或者“微软发布。。。”，把个人意见作为公司立场。这种误解不会使好的事情变得更好，却会使坏的事情变得更糟，比如Oxite这次造成的错觉。因为据Scott Hanselman的解释，Oxite这次推出并没有经过内部规范流程的审查：
The fact that PhilHa, who owns ASP.NET MVC, didn't know it was going on, kind of makes that point. Any samples from Microsoft that intend to show a Best Practice should be reviewed by Phil, and certainly vetted by the community. David Nelson nailed that point clearly.
最后，Glenn Block为此次事件做了解释，同时，Rob Conery也开始帮助MIX Online团队对Oxite进行重构。从架构设计和项目管理上，这次Oxite事件都给了我们深刻的反思：
- 要谋定后动
- 要虚心倾听