.NET发展中的几个失误

  [ 前不久与一个朋友通过信件讨论技术发展的趋势,其中提到我对于.NET发展的一些看法,节选部分发表。由于是私人信件,语言偏激错误之处在所难免,且仅代表我个人观点。]

       我一直认为,.NET是目前设计的最漂亮的基础软件平台,这个平台从设计之初,就对与一些长期困扰软件开发者的老问题从根本上进行了重新考虑,并且给出了非常好的解决方案。比如像Assembly的概念,像AppDomain的概念,对于安全问题的解决方案,确实是考虑得非常周到。.NET刚出来的时候,像Jeffrey Richter,Jeff Prosise等老牌微软技术专家,都在兴奋地高呼看到了软件开发的未来,这种呼声恐怕也不能完全看成是替微软在摇旗鼓吹。事实上,.NET本身的优越性不仅仅征服了微软阵营,也征服了一部分开源技术专家。GNU组织就启动了一个项目来模仿.NET,这应该是对于.NET技术优越性的最佳注脚。

    然而几年下来,.NET的发展符合微软的预期吗?符合曾经对微软迷信得如痴如醉的fans们的预期吗?恐怕不是这样的吧。

    .NET技术是出色的,但是执行上大大小小失误的地方有很多。从大的方面来讲,像.NET这样面向Internet的技术体系,本质上必须跨平台。只有跨平台,才能覆盖网络上的各个节点,使本来是异质的网络同质化,使.NET成为Internet的API,如果能达成这个目标,则.NET就千秋万代了。但微软并没有这样做。在将.NET扩展到Linux、FreeBSD等其他Internet主流平台上的过程中,微软的表现始终是犹犹豫豫,模模糊糊,非常暧昧。为什么这样明显具有重大战略意义的步子却总迈不开?最简单的猜测是,微软担心这样做会客观上鼓励人们使用Linux/FreeBSD等操作系统,从而间接削弱Windows,直接打击微软的主要利润来源。另外,.NET本身还处于快速变迁中,战线拉得太长也会带来技术体系维护上的难题。今天的微软已经是一个大公司,各部门各产品线之间的利益关系交错复杂,即使是明显正确的决策也要在官僚主义的台球桌上撞个七荤八素才能落袋,何况像.NET跨平台这样重大的战略性决策。总之,直到现在,我们仍然只能在Windows上使用.NET(不要跟我较真提什么Mono)。这样就把一个本来能够成为覆盖Internet的未来软件环境变成了Windows本身的一个API升级版,战略意义折损大半。回想一下2000-2002年间.NET的那些初期宣传,什么XML,Web Services,什么.NET My Services,多么激进的面向Internet的计划!有人说当时微软对技术发展趋势判断失误,这是胡说。哪里有失误?XML难道不是已经成为网络数据描述的标准了吗?Web Services难道不是为SOA奠定了基础吗?.NET My Services难道不正是今天Google梦寐以求想做的事情吗?哪里有错?只不过自己不坚定,见势不妙就打退堂鼓而已!

    即使从Windows API升级版的角度看.NET的执行与推广,失误仍然很大。微软在向.NET转移的过程中,对于如何处理好上一代技术(基于C/C++/COM)与.NET过渡的问题上表现得很不成熟。几个月内过火的宣传排山倒海,把对手们吓得心惊肉跳,把fans们搞得心驰神迷,把自己也灌得晕晕乎乎,可以说是乱了敌人也乱了自己。什么可以马上转?什么要有中长期的转型计划?什么坚决保持稳定?上上下下发生了严重的思想混乱。结果在技术平台过渡这样重大的战略步骤中出现强行军、大跃进的左倾机会主义行为。可以肯定地说,Windows Vista的严重跳票,与激进的技术转型有直接的关系。回顾历史,想想微软从DOS过渡到Windows时代的战战兢兢,周全稳妥,令人不仅唏嘘,同是一家公司,前后差别咋就这么大呢?

    让我们再退一步,看看整天跟我们打交道的这几个.NET编程语言好了。微软在微观层面上最大的失误就是对VB.NET语言发展方向的决策失误。本来,在.NET平台上的三种主流语言VB、C#和C++有一个非常清晰的定位。C++专攻底层,与CLR同级,开发效率放两旁,把“强”字摆中间。C#作为CLR上的系统语言,解决.NET上的系统软件开发,开发效率和功能兼顾,但也绝不在哪一边冒头。这样一来,留给VB一个光荣使命——应用开发。VB应该是一个强调生产率,强调简便易用,快速开发的语言,凡是跟这个目标相冲突的,都可以请出VB,脏活累活让C#和C++去做吧,让我们VB漂漂亮亮体体面面地去做very high level language,在开发效率上5倍10倍地超过C#,那才是VB的使命!历史上VB在微软技术体系里不是一直扮演这样的角色吗?历史上VB在这个角色上的表现不是一直都很杰出吗?CLR是干什么的?语言互操作为了什么?不就是为了各个语言各展所长,最后一对接,天衣无缝,皆大欢喜吗?难道我没事创造20种同一个level,表达能力相同,连语义模型都差不多的语言耍着好玩吗?

    可是你看看VB.NET干了什么?在Perl、Python已经充分证明了动态语言在生产效率上的威力之后,VB.NET不但没有在VB6的基础上进一步走向动态,走向高生产率,反而往回缩,语言变得比以前更严格了,加强了类型系统的约束,一大堆对生产效率有影响的复杂面向对象特性被毫不犹豫地加入VB,一个简单明快的VB变成了庄严肃穆VB.NET,变成了C#的等价Basic版。如果没有C#,这一切都没什么错误,可是有了C#,还放一个几乎可以句对句翻译的VB,有什么意义呢?除了让老VB6的开发者悲愤欲绝,除了把.NET开发人员毫无必要地划分为两个不能自由沟通的阵营,除了让MSDN文档的长度延长一倍之外,对于开发者提供了什么实质的好处吗?其结果是,.NET主流语言体系里出现了一个基础语言,两个生产率和能力等价的中级语言,而在高生产率的应用开发语言这一栏里,写着一个“暂缺”。

    现在VB的那些产品经理大概总算意识到了这个问题,在VB的My名字空间里加入一大堆方便的特性。很好,你们终于看清楚VBers的脑门上写的是什么了:不尚虚名,只求实效。可惜啊,晚了!
 

已标记关键词 清除标记
课程简介: 历经半个多月的时间,Debug亲自撸的 “企业员工角色权限管理平台” 终于完成了。正如字面意思,本课程讲解的是一个真正意义上的、企业级的项目实战,主要介绍了企业级应用系统中后端应用权限的管理,其中主要涵盖了六大核心业务模块、十几张数据库表。 其中的核心业务模块主要包括用户模块、部门模块、岗位模块、角色模块、菜单模块和系统日志模块;与此同时,Debug还亲自撸了额外的附属模块,包括字典管理模块、商品分类模块以及考勤管理模块等等,主要是为了更好地巩固相应的技术栈以及企业应用系统业务模块的开发流程! 核心技术栈列表: 值得介绍的是,本课程在技术栈层面涵盖了前端和后端的大部分常用技术,包括Spring Boot、Spring MVC、Mybatis、Mybatis-Plus、Shiro(身份认证与资源授权跟会话等等)、Spring AOP、防止XSS攻击、防止SQL注入攻击、过滤器Filter、验证码Kaptcha、热部署插件Devtools、POI、Vue、LayUI、ElementUI、JQuery、HTML、Bootstrap、Freemarker、一键打包部署运行工具Wagon等等,如下图所示: 课程内容与收益: 总的来说,本课程是一门具有很强实践性质的“项目实战”课程,即“企业应用员工角色权限管理平台”,主要介绍了当前企业级应用系统中员工、部门、岗位、角色、权限、菜单以及其他实体模块的管理;其中,还重点讲解了如何基于Shiro的资源授权实现员工-角色-操作权限、员工-角色-数据权限的管理;在课程的最后,还介绍了如何实现一键打包上传部署运行项目等等。如下图所示为本权限管理平台的数据库设计图: 以下为项目整体的运行效果截图: 值得一提的是,在本课程中,Debug也向各位小伙伴介绍了如何在企业级应用系统业务模块的开发中,前端到后端再到数据库,最后再到服务器的上线部署运行等流程,如下图所示:
©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页