博客园_Kanas.Net Blog

永中科技倒闭的另一面

2011-04-09T18:18:00Z

上周四，当看到有关永中科技倒闭的消息时，我相当震惊。园子里转了这条新闻，但是似乎没有引起多少反响。刚刚看完了《非战之罪，从永中Office谈起》，对于“主要是外部环境的问题”这一结论还是相当赞同的，不过文中关于QQ、WPS之类的结论显然太多作者自己的主观成份，就完全不敢认同了。事实上关于这些产品的问题与永中Office没有太大的关系，我也不愿再讨论了。关于作者的结论我还想作一些补充。

1.技术方面我没有什么发言权，因为我从来没有用过。但是如果是一款Java特别是Swing写的客户端我是一定会拒绝使用的，无论你的东西写得多么有创意。当然，C#或者VB.NET写的也不会例外。客户端的软件必须是Native的，可以是C/C++。跨平台与Java之间没有必然的联系，除了二进制级别的跨平台以外还有源码级的跨平台。何况100%二进制跨平台根本就不存在。当然，我的主观判断，永中Office是一款有足够技术含量的产品，与所谓的“汉芯”、“麒麟”、“驴坝”有着天壤之别，这一点我不怀疑。这也是令我震惊的地方，毕竟“麒麟”都还活着。

2.倒闭不一定是坏事，没有必要觉得有多么悲壮。永中科技倒了，但是这么一款产品，绝对不是说倒就可以倒的，其中所含的技术成份决不是一点一滴的，基于这个产品大量的技术细节，仍然有可能做出更好的、产权更清晰的产品来。如果进行重组，浴火重生也不是完全没有可能的。毕竟没了包袱更轻松。再者说了，即使永中彻底消亡了，还会在行业内引起反思，有的学费可能真的免不了。

3.软件企业的生存与发展异常困难，倒不全是因为盗版，而是因为大环境。郭嘉花大把钱支持软件这个产业无疑是灰常灰常英明的，但可惜的是对行业的推动力与所支出的金额相比实在是不成比例。究其原因主要是两个方面：其一，gov特别是地方gov政绩欲太强，不愿意担当风险，哪怕是极小的风险，Ta们只愿意将钱投入到“锦上添花”的地方而不是“雪中送炭”的地方。其二，gov投入到软件企业的钱真正能落到实处的少之又少，大部分漏掉了，官员们贪一点、企业老总们铺张一点(反正是郭嘉的钱浪费起来不用心疼，毕竟没人监督这些钱的使用)、项目中的花架子部分再耗掉一点，层层剥皮以后，能真正用到项目中的我估计也就一成不到吧。谁为你流泪谁为你心疼谁送你上征程。

4.我是个阴谋论者这个我老老实实承认。我不用任何杀毒软件除了MSE，只因MSE随OS授权，没有利益链。神马免费杀毒，都是天上掉馅饼的幼稚幻想。“永中软件”怎么来的？2500万还顶不了4000万的亏空，搞这么个第三者出来是不是等郭嘉1.8亿到帐后，合理合法地装一部分到私人口袋里？别以为我是小人之心度君子之腹，你以为当年新太是如何垮掉的啊。在资本世界里(特别是在一种监督机制严重缺失的初级资本世界里)，如果人对金钱的贪欲普遍大过对信托精神的崇拜，一定是几家欢喜几家愁的结局，这太正常了。很多时候不是因为没有陷阱，是因为你看不到。如果你都能看到了，那还能叫陷阱呀。

本文链接

ASP.NET MVC + ADO.NET EF 项目实战（三）：引入jQuery

2010-03-08T14:54:00Z

jQuery是一个重要的客户端框架，ASP.NET MVC默认的项目模板中就带了这个框架。掌握这个框架对于更好地编写ASP.NET MVC应用是非常重要的。事实上，网上有很多文章讲述如何在ASP.NET MVC项目中使用jQuery。例如以下文章就是讲关于jqGrid的：

Using jQuery Grid With ASP.NET MVC

Using jqGrid with ASP.NET MVC

另外，在CodePlex上就有很多项目帮助你更方便地应用jQuery，例如：

jQuery UI Extensions for ASP.NET MVC
jQuery Grid for ASP.NET MVC

但是，要更加方便地使用jQuery，仅仅知道以上还是不够的。

一：了解ASP.NET MVC的局限性

ASP.NET MVC有几处是我不太喜欢的，但是似乎也没有太好的解决方案。

第一件事情是冗余的Action。在一个Controller中每个Action的地位是平等的。但是很遗憾，一个带Form的View总是需要两个Action，一个用来GET；另一个用来POST。而我觉得这两个Action是不平等的。用于Post的Action是依赖用于Get的Action的。我告诉你，这两个Action其实是可以压缩成一个的。另一个完全可以放到System.Web.Mvc中，大家公用，通过传递一个或多个delegate来处理。也就是说，形式上是一个，实际上仍然是两个。说这个问题的意图是想说明，我们可以把一个Ajax服务通过传递一个delegate来实现单入口。

第二件事情是Script的Render。我希望任何TagBuilder都可以引用自己的Script，在Html的Head段最后写入。可惜WebFormViewEngine的Render过程中按次序进行的。这意味着，直到整个页面写入Response你都没有机会去更正对Script的引用。其实我以前写过关于ASP.NET MVC中Script的管理，不过实话说非常丑陋。其实我也可以告诉你，这个是可以实现的。在View中可以定义一个特殊的标签，当遇到这个标签的时候，将已经生成的Html写入缓存，清空HtmlWriter，再Render剩余的部分；最后再Render Script部分，最后交这三者合并，最后写入Response。说这个问题的意图是将客户端复杂化以后给应用带来的困难暴露出来。

任何一件事情，如果单独在服务端完成，这个比较好处理。如果单独在客户端完成，这个也好处理。如果需要客户端和服务端配合，就会弄出一些麻烦来。如果你要在一个页面中显示一个jqGrid，你一共至少需要做四件事情：

1.在你的View中加入相关的引用，包括JavaScript和CSS；包括jQuery、jQuery UI、jqGrid；包括相关的主题。

2.在你的View中适当的地方添加一个table标签，并加上id，用于表格的容器；再添加一个div标签，也加上id，用于分页器的容器。

3.加入相关的脚本，将网格与给定的标签进行绑定。其中需要定义网格的列信息。

4.加入一个数据获取的Action，或者XML格式数据或者JSON格式数据。

对于第1件事情，似乎不算麻烦。如果不是过于挑剔的话甚至没有什么问题。

对于第2件事情和第3件事情，就会有冲突了。可以假设这两件事情是两个人做的，但是他们必须确保他们所使用的id是一样的。一旦不一致，到底算谁的责任？

对于第4件事情，就更麻烦了。因为那已经是服务端的事情了。不仅获取数据的Url要正确，连Column表和数据表也必须一致。一旦不一致，到底算谁的责任？

通常对于要求一致的事情，由一个人做比较好。所以，无比聪明的程序员会通过一个 HtmlHelper来根据单一的定义统一生成。这的确是一个好的思路。所以，使用jQuery是需要进行专门包装的。

二：封装jQuery及其插件

如果要一个基于jQuery的Total Solution，还真有比较大的困难。jQuery本身的功能是相当有限的，其丰富的功能要依赖一大堆的插件。几乎每个插件要用在ASP.NET MVC中都需要包装一下。好在jQuery插件有一些约定，所以封装起来相对比较简单。在封装的时候有一点通常容易被忽略的是：作为独立于应用的封装模块中是可以带自己的Controller的。举个例子来说：如果你封装了一个jQuery UI的主题管理器，主题管理的ModalDialog的Action，包括Get和Post你都是可以包装在一个单独的项目中的。如果你的控制器叫 jQueryController，两个Action分别是ShowThemes和SetTheme，那你可以通过以下代码来实现：

var currTheme = "";
        $(document).ready(function() {
            var doClick = function() {
                $("#themeGallery td img.currentTheme").removeClass();
                this.setAttribute("class", "currentTheme");
                currTheme = this.getAttribute("title");
            }
            var doOK = function() {
                $.post('/jQuery/SetTheme', { theme: currTheme }, function(data) {
                    $("#themeDialog").dialog("close");
                    eval(data);
                });
                return false;
            }
            var doCancel = function() {
                $("#themeDialog").dialog("close");
            }
            $("#themeDialog").load("/jQuery/ShowThemes");
            $("#ThemeButton").click(function() {
                $("#themeGallery td img").click(doClick);
                var dialogOpts = {
                    modal: true,
                    width: "662px",
                    height: "420px",
                    resizable: false,
                    buttons: { "OK": doOK, "Cancel": doCancel }
                };
                $("#themeDialog").dialog(dialogOpts);
            });
        });

这样，在任何需要设置主题的地方放一个<a>元素，id定义为ThemeButton即可。基于同样的原理，我们在封装jqGrid的时候，可以使用如下定义的委托：

public delegate GridDataModel QueryableFunc(HttpContextBase context, int page, int rows, string sidx, string sord);

这样，单一的入口就是：

        public ActionResult Employees()
        {
            var model = new GridModel
            {
                Caption = "Employees",
                Loader = (ctx, page, rows, sidx, sord) =>
                {
                    ...... 实现数据访问
                    return new GridDataModel
                    {
                        Total = q0.Count(),
                        Page = page,
                        Records = q.Count(),
                        Rows = q.ToArray()
                    };
                }
            };
            model.Columns.Add(new ColumnModel
            {
                Name = "Id",
                Width = "80px",
                Align = ColumnAlign.Right,
                Caption = "Id",
                Index = "Id",
                IsKey = true,
                Sortable = true,
                Hidden = true
            });
            ...... 加入其他列
            return View(model);
        }

这样，在View中使用的扩展，生成的JavaScript代码中，Url是由应用无关的模块提供的，以View名称+View中Table的id为标识，存贮在服务端。获取数据时提交该标识，找出数据加载器，从而实现异步数据加载。

jQuery的插件，除了jqGrid是必须封装的以外，jQuery UI也是必须要封装的。虽然很多人包括我在内，对jQuery UI有诸多不满，主要的不满都是基于功能，项目进度严重拖后于Roadmap上的承诺。另外，其代码质量也不如jQuery。不过，毕竟jQuery UI是jQuery官方的产品，受到很多插件依赖，所以，暂时没有可替代的。

此外，还有以下插件需要封装：

带CheckBox的TreeView；
导航Menu和上下文菜单；
封装Google Maps API的gMap；
tinyMCE的jQuery插件；
用于布局的Panel插件；
动态Form插件。

三：如何避免拼凑脚本

在ASP.NET MVC中需要经常拼凑脚本，这一点也非常令人讨厌。讨厌的并不是“拼凑脚本”，而是“经常”。需要“经常”拼凑脚本的原因是服务端的内容是动态输出到客户端的。如果通过某种固定的机制，智能地将服务端的单一代码自动生成为客户端内容那将是非常令人高兴的事情。换句话说，你在服务端直接写C#代码，然后有一个专门的工具将这些代码翻译成客户端代码。

我研究过JavaScript#，发现这条路完全行不通。首先，要么翻译源码、要么翻译编译后的代码，但必须是整个文件地翻译，而不能是某个代码段。其次，JavaScript#必须依赖一整套程序集，而这些程序集是特有的。

我建立了一个新的项目，叫jQuery#，基于一套专门的库，然后在运行时以较小的代价来实现反编译，并翻译成JavaScript代码。如果仅仅只是生成jQuery所需要的客户端代码是非常简单的，jQuery API毕竟比较少，每个插件的API也都相当有限。麻烦的是需要插入大量的客户端Event Handler。这才是难点所在。按我的计划，今年6月初会发布jQuery#的第一个版本。目标是可以这样写View：

<% Html.jQuery(document => {
    new jdGrid{
        container = "main",
        clientId = jQuery.CreateTable("employees"),
        pager =  jQuery.CreateDiv("empPager"),
        data = Model,
        open = () => {
                jQuery.Element("OpenButton").Disable();
                return false;
            },
        caption = "Employees"
}); %>

本文链接

虎年刚开头，给大家拜个年...

2010-02-16T03:43:00Z

今天是大年初三。园友们新春愉快，虎年行大运、发大财！

昨天，Microsoft在巴塞罗那发布了WindowsMobile7。一直以来我都是用WM手机，不过这次WM7并没有让我看到亮点。

前天，索尼官网上发布了Z11系列的VAIO。i7-620m的芯片，1920X1080分辨率，512GB的SSD，1.4Kg。虽然我一直用Thinkpad，不过这次的Lenovo连i5-520m、独立显卡的T410s都还没有正式发布。作为一名ASP.NET应用开发人员，合适的本本应该是这样的：

1.多核，最好四核；必须支持64位Windows Server 2008 R2。

2.显然，内存不能少过4G。毕竟你可能需要在一台本本上同时跑SQL Server 2008R2、IIS和VS2008或者VS2010。

3.显示分辨率要够高，标准的WXGA是肯定不够的，特别是高度，必须900以上。我已经适应了1400X1050，不过如果再高一点我也不会介意。

所以，你也会和我一样欣赏SONY VAIO VPCZ119GC。￥29999，价格比普通CORE 2 CPU的ThinkPad T400s 2815H16的￥37599还低许多。呵呵，原来Thinkpad还在希望靠原来的光环生存。

本文链接

每一个社区成员，用你的努力为微软平台的开发技术添上一把柴！

2010-02-05T09:18:00Z

我必须先声明，我不愿意陷入平台之争，如果有人要争，恕不奉陪。昨天园子里有篇文章，就一个Session的访问问题写了一篇文章，批评ASP.NET的不足，而且莫名其妙的一个结论是“ASP.NET不能构建大型Web应用” 。无厘头。其实这个很正常，毕竟这么大一个社区鱼龙混杂的。不正常的是有些社区大佬们没有站出来，反而有点站在旁边看热闹的味道。我想说的是，你以为与你无关吗？昨天一...

POCO真那么重要么？

2010-01-06T19:12:00Z

不断听timiil向我介绍Entity Framework 4.0的诱人之处。当然，他知道我最需要的是稳定且实用的设计时和提供给我从模型到数据库的设计体验，这两点是EF1.0不能满足我的。之所以我特别在意这两点，是为了满足我经常性修改模型的现实要求。显然，EF 4似乎有所改善，但显然离我的要求仍然有相当大的距离。刚看到的一篇介绍EF4的文章，似乎比较喜欢POCO，这让我相当意外。那么，POCO真那...

也说 ASP.NET MVC的 Script 管理

2010-01-03T11:56:00Z

WebForm下的ScriptManager在ASP.NET MVC下自然是不能使用的。于是很多人开始困惑如何管理页面上可能发生冲突的脚本。CodePlex上还有一个项目专门做这件事情，当然也有人简单地通过HtmlHelper来解决。如果你看过jQuery UI Extensions for ASP.NET MVC，或者是jQuery Grid for ASP.NET MVC，你还会找到更多的解决...

IT风云录(开篇词)：我们从David Cutler学到什么？

2009-12-16T18:10:00Z

DavidCutler何许人也？Google一把你就明白了。2008年获得了美国国家科技和创新奖章，这个奖大概相当于我们国家一年一度的国家科技奖吧，无论如何这是一种不平常的荣耀。尽管他的故事还没有真正成为过去，毕竟到现在为止，他仍然担任着微软云计算平台（AzureServicesPlatform）的主要开发者。但是已经有太多需要我们去解读和学习的精神，已经有太多需要我们去细细品味的哲理，已经有太多...

ASP.NET MVC的RAD之路(一)

2009-12-10T04:07:00Z

嗨。或许我有极重的RAD情结，当我第一次弄明白ASP.NET MVC架构之后，我忽然发现，RAD有了希望。大多数情况下，当你的Model不幸被修改了，不得不去修改View。而从Model到View的映射还不得不让人来处理，也就是设计时的处理。Visual studio 2008在我们第一次创建View的时候可以帮一点小忙，而修改根本就无能为力了。其实我的期望比较的现实，大概就是ObjectGrid...

ASP.NET MVC + ADO.NET EF 项目实战（二）：设计过程与设计工具

2009-09-29T08:36:00Z

工欲善其事，必先利其器。好的工具能够成倍提升工作效率。ASP.NET MVC和ADO.NET EF也是因为其工具出色而受到欢迎。例如： MVC所提供的View模板工具； MVC所提供的View切换、向导工具； ADO.NET EF提供的模型设计工具； ADO.NET EF提供的数据库模型导入工具。本文仅仅讨论项目实战中的设计工具。需求设计工具本文所指的需求设计是指将需求规格说明书(SRS)展开...

体验ADO.NET Entity Framework的继承

2009-09-04T04:54:00Z

ADO.NET Entity Framework(以下简称ADO.NET EF)有一个非常可信的运行时。之所以不敢在项目中广泛使用是因为其糟糕的设计时。这个DSL设计时糟糕在哪里呢？其一，只能是先设计好数据库后设计实体模型；其二，如果你修改了数据库结构，再更新实体模型时，你所做的修改全部作废，最糟糕的是，很可能会出现映射错误，你必须手工来维护EDMX中的MSL部分。通常数据库结构的修改会成为你的噩...