领导力大挑战
在实施Scrum项目的过程中,Scrum Master的角色是相当关键的,因为他是团队的推动者。本文围绕什么是仆人式领导、仆人式领导的起源、如何将领导力传达给团队、Scrum Master作为仆人式领导者的角色展开叙述,同时重点阐述仆人式领导者应有的基本内外特征。
该内容已经被标记书签!
标记书签错误,请重试!
作者 Jon Arild Tørresdal 译者 王瑜珩 发布于 2009年5月6日
最近几周,在博客、Twitter和论坛上如火如荼地展开了一场讨论。讨论的内容是:开发人员是否应该使用或学习ASP.NET MVC。从“不推荐学习”到“所有ASP.NET开发人员都应该学习”,各种不同的观点层出不穷。InfoQ对其中部分讨论内容进行了总结。
Rob Conerey(SubSonic之父,目前是微软ASP.NET MVC团队的一员)解释了为什么开发人员应该学习ASP.NET MVC。在文章的开始,他称WebForms是一个“巨大的谎言”。
WebForms是个谎言,它是一个被种种谎言和欺骗所包围着的抽象机制。你对WebForms所做的一切都与Web无关 - 它帮你做了本该你自己做的事。
朋友们,这可是件大事(至少对我来说):你工作在谎言中。Web是“无”状态的,它依赖一种叫做HTML的东西,并使用另一种叫做HTTP的东西通过电缆将HTML发来发去-你需要了解它、热爱它并在骨子里感受它。
Rob列举了7个使用ASP.NET MVC的理由,或者用他的话说“避免被称为怪人的7个理由”:
然后总结到:
结论:Web编程再一次充满了乐趣,至少对我和我的猫来说。当然这又是一个关于WebForms和MVC的比较,但是更直接一些。你几乎无法找到不学习MVC的理由 - 当然,对你来说可能还是有一两个理由,促使你继续使用WebForms。
Joe Brinkman(DotNetNuke的全职开发人员)迅速的做出了回应,批评Rob没有找到一个“好”的学习MVC的理由,并列出了他自己的:
Joe总结道:
你真的应该试一试MVC,但不是因为Rob所列举的那些原因。你应该尝试,MVC是因为最终你会学到一些东西,它可以使你成为更好的Web开发人员,这与你最后选择了哪个平台无关。
Rob和Joe基本上都同意,ASP.NET开发人员应该学习ASP.NET MVC,但是对于学习的原因还有争议。然而Karl Seguin持有不同的观点,他质疑道:“ASP.NET MVC是一个半成品么?”:
能够以更清晰的方式构造复杂的系统是一个好的开始,但是对于一般的Web开发,特别是与其他平台比较来说,ASP.NET MVC还是要落后很多(Perl是我能想到的唯一一个更糟糕的)。
最大的问题在于,它只是一个VC - 没有对Model的考虑、支持和相关的工具。当你将自己写的数千行repository/dal/linq/nhibernate代码与其他MVC平台(通常只需要你的model继承一个类)比较时,你显然已经在生产力方面处于严重的劣势。但是深层次的影响更糟 - 你失去了controller和view上的内聚性,没有任何方法可以从Model的属性来自动生成HTML标签或者是客户端验证。
……
当然ASP.NET MVC也有好的方面,它的体系结构是可重用的,这使得像S#arp Architecture这样的项目得以实现。然而我仍然怀疑,这样的项目是否真的能够比集成的更好的框架更成功。
Jeremy D. Miller(FubuMVC的创造者之一)列出了一些正面的和负面的因素:
负面的:
……除非你愿意卷起袖子构建你自己项目的体系结构来充当“M"、获取更好的测试性、拥有更简单的视图同步机制以及更高效的Html helpers,否则ASP.NET MVC的生产力并不高……
正面的:
使用这个MVC框架很简单和直接,还可以根据需要进行定制。
Jeremy总结道:
我觉得ASP.NET MVC最终会是一种比“被种种谎言和欺骗所包围着的抽象机制”更好的Web程序开发方式,但是现在它仅仅适合那些乐于尝鲜的人。
Jeffrey Palermo(目前正在撰写“ASP.NET MVC in action”)发表了“你不应该使用ASP.NET MVC, 如果”:
他继续说道:
ASP.NET MVC不是一个“束缚你手脚”的框架,也不是一个“ASP.NET入门”框架,你可以完全控制所有的东西。在Web的世界里,UI还没有标准化到可以使用框架来控制,并以一种“标准”的方式来生成。相反数据访问已经可以了,我们知道我们需要创建、读取、更新、删除、级联存储、延时加载等等。很多ORM都支持这些操作,很多开发人员放弃了对数据访问的完全控制,因为这和ORM(Hibernate/NHibernate)工作的方式非常相似。
虽然还有其他很多人也表达了自己的观点,但是InfoQ认为本文已经覆盖了绝大多数对于学习/使用ASP.NET MVC的观点。
查看英文原文: Should ASP.NET Developers Learn ASP.NET MVC?
译者 王瑜珩 InfoQ中文站编辑,ThoughtWorks咨询师,关注企业级Web开发、敏捷实践以及项目管理。
我一直不想学asp.net就是他的web form太TNND让我头疼。。我也没有办法我用起来就感觉MD 太让人
没有真正深入接触过一种技术的人没有资格对这种技术进行任何评论。
WebForm 的确是不少的问题,它抽象了太多的东西,我感觉用来做一个很简单的 Web 项目而且定制要求不高时它还可以体现一些生产效率,但是复杂的 Web 项目和定制化要求高出 WebForm 表现力时,使用 WebForm 就很痛苦了,这种时候真的需要 ASP.NET MVC 这样能够对 HTML 有更多控制力的框架来使用。
个人特别不喜欢ASP.NET自动生成的HTML代码,因为讨厌其中hidden标记中的大量数据和自动生成的div标记。还是特别喜欢“纯净”的HTML代码,这点JSP做的很好。“纯净”HTML代码有助于我们做客户端的JS。
一个页面 (.Net FW 2.0) 使用DataGrid呈现数据, 一行约有30个Textbox, 其中约有16~20个需要进行输入验证
前一个开发组选择的方法是使用内建的验证控件CompareValidator, 上线时, 生成的页面运行速度异常缓慢
通过对HTML分析, 发现包含近70行数据的页面大小达到2.8MB (纯字节)
这是什么概念?
我把页面上近90%的Validator删去, 使用JS编写验证代码, 最终页面大小缩减成1.3~1.5MB, 减了1MB以上
页面所使用的ComapreValidator的判断逻辑是一致的, 不同的只有目标控件
.Net产生了1MB的冗余代码, 而我编写的JS仅为3KB (未压缩), 差了上百倍!
(注: 使用了jQuery, 额外增加了约60KB的数据传输)
我还是喜欢MVC方式
建议你去看看博客园老赵的“为webForms说几句话”系列。也许你就没有这样的想法了。 起码你不会再觉得webForms有以前你感觉的那么差劲。
在实施Scrum项目的过程中,Scrum Master的角色是相当关键的,因为他是团队的推动者。本文围绕什么是仆人式领导、仆人式领导的起源、如何将领导力传达给团队、Scrum Master作为仆人式领导者的角色展开叙述,同时重点阐述仆人式领导者应有的基本内外特征。
论道WP第三篇专栏,以应用程序栏的使用为中心,包括了软键盘带来的问题、应用程序栏介绍、如何绑定应用程序栏的属性等几个方面的具体话题,为开发者顺利使用应用程序栏开发提供了具体指导。
在多线程并发编程中Synchronized一直是元老级角色,很多人都会称呼它为重量级锁,但是随着Java SE1.6对Synchronized进行了各种优化之后,有些情况下它并不那么重了,本文详细介绍了Java SE1.6中对于锁的性能优化,以及锁的存储结构及升级过程。
本次分享将首先介绍现代富文本编辑器的组成和实现,然后结合UEditor的开发过程,与参会者分享UEditor在设计和实现的过程中,所涉及到的核心功能的细节实现。
本次演讲视频录制于百度技术沙龙。
我们所开发的应用程序大多都需要提供一个图形用户界面(GUI)。关于GUI应用的架构设计,已经有了Form & Control、MVC,、MVP、 Passive View等多种模式。模式可以帮助我们建立优雅的架构,但前提是弄清楚模式的应用场景。弄清楚GUI应用面临的设计上的问题,有助于我们正确的挑选设计方案。
MongoDB是一种非常易用的NoSQL方案,Brian C. Dilley在这篇文章里介绍了MongoDB的优劣势,并介绍了MJORM项目。MJORM用于MongoDB,是一个没有注解的Java ORM库。
随着网络基础设施的逐步成熟,从RPC进化到Web Service,并在业界开始普遍推行SOA,再到后来的RESTful平台以及云计算中的PaaS与SaaS概念的推广,分布式架构在企业应用中开始呈现出不同的风貌,然而殊途同归,这些分布式架构的目标仍然是希望回到建造巴别塔的时代,系统之间的交流不再为不同语言与平台的隔阂而产生障碍。
6 条回复
关注此讨论 回复