博客园_xiaosonl的研究档案

学习手札#3 NHibernate缓存

2010-06-05T16:49:00Z

NHibernate主要有三种缓存:

1. 一级缓存.

一级缓存的生命周期和作用域只在同一Session中, 以[主键-对象]方式存放.

2. 二级缓存.

二级缓存的生命周期和作用域在同一SessionFactory中, 同样以[主键-对象]方式存放. 二级缓存的读取读取优先级不如一级缓存高, 所以当SessionA和SessionB中都存在同一对象的一级缓存时, 其中一个Session更新对象缓存, 另一个Session会因为优先读取一级缓存而返回未更新的对象.

3. 查询缓存.

查询缓存的生命周期和作用域同样只于同一SessionFactory中, 以[查询语句-对象ID序列]方式存放, 即只缓存查询结果集的所有对象ID. 当查询数据发生改变(增加、删除、修改等)，查询缓存会将其从缓存中删除. 该过程比较不透明, 建议使用查询缓存还是根据程序业务来制定较好.

本文链接

产品的简单性

2010-05-31T06:29:00Z

产品的简单性，包括功能上的简单和非功能上的简单。

功能上的简单，指产品使用简单，上手容易，一看即会操作，功能无歧义。

非功能上的简单，多指设计上的简单，易懂易维护。

这两方面的简单性很难兼顾，功能上的简单，可能掩盖着复杂的设计。比如ASP.NET的WebForm，使开发网站项目变的跟WinForm一样简单，但是WebForm的设计是很复杂。相比ASP.NET MVC，虽然使用繁琐，但是设计清晰简单。

所以在考虑简单性设计时，一定要在两者间做好取舍。

本文链接

关于过度设计的思考（上）

2010-05-30T07:18:00Z

设计是一个取舍的过程，无论是过度设计还是设计不足的问题，都是取舍的结果：

1. 如果不预先设计，随着时间越久，更改成本越大

2. 如果预先设计，会增加当前程序的复杂度

这种取舍没有放之四海皆准的标准，需要根据不同项目不同人员做选择。在我开发经验当中，总结几条参考标准：

1. 可隔离的实现不做优化设计，当性能需要时再进行优化，需要单元测试支持。

2. 如何为扩展性预留设计？

这是个很纠结的问题，这里面其实有两个概念：扩展和设计。设计是为了扩展，但是设计不能完全解决扩展问题，如果非要用设计解决所有的扩展问题，那基本上就会造成过度设计。其实很多大型项目，到了一定阶段，就是基本上重写架构了。这时候，相比可扩展的复杂设计，倒不如简单的设计，但是因为设计简单，所以代码更易懂，更容易被重写。之前看到过一句话：有一种设计，很复杂，不会有明显的问题；有一种设计，很简单，明显不会有问题。我们应该选择后者。

本文链接

让ASP.NET MVC的Controller输出不同类型数据

2010-05-30T05:58:00Z

ASP.NET MVC中，可以通过返回不同类型的ActionResult来输出不同内容，比如ViewResult会输出视图页，JsonResult会输出Json数据等等。

而有时会遇到同一个Controller需要支持输出不同类型的情况，比如正常查看一个用户的资料页时，用/User/{id}就可以访问到；而在JavaScript或其它系统中需要查看用户资料，又希望/User/{id}能返回Json数据。这种情况可以通过构建一个自定义ActionResult来实现，根据参数返回默认的ViewResult，或者将Model序列化为指定的类型输出，其实就是控制Model的输出行为。输出类型的参数，可以通过两种方式来传递，一个种传统的Get或Post传参：/User/{id}?rtype=json；另一种可以通过Http请求的ContentType参数来指定类型:request.ContentType = “json”.

附参考代码：

public class AutoResult : ActionResult
    {
        public string ViewName { get; set; }
        public object Model { get; set; }

        public override void ExecuteResult(ControllerContext context)
        {
            string type = context.HttpContext.Request["rtype"];
            if (string.IsNullOrEmpty(type))
            {
                type = context.HttpContext.Request.ContentType;
            }

            if (!string.IsNullOrEmpty(type))
            {
                switch (type.ToLower())
                {
                    case "json":
                        new NJsonResult(Model).ExecuteResult(context);
                        break;
                    case "binary":
                        new BinaryResult(Model).ExecuteResult(context);
                        break;
                    case "xml":
                        new XmlResult(Model).ExecuteResult(context);
                        break;
                    default:
                        context.HttpContext.Response.Output.Write("无法识别的类型");
                        break;
                }
            }
            else
            {
                context.Controller.ViewData.Model = Model;
                ViewResult viewResult = new ViewResult() { ViewName = ViewName, ViewData = context.Controller.ViewData };
                viewResult.ExecuteResult(context);
            }
        }
    }

本文链接

学习手札#2 故事点和小时数的思考

2010-05-26T13:27:00Z

故事点与小时数这两种度量单位，最大的区别在于, 故事点数是整个团队中通用的度量方式，不会因为经验、个人技术水平或团队某个人而受到影响。比如第一周完成的故事点和第二周完成的故事点差不多，就可以基本认为两周的任务完成量相当；而如果第一周所消耗的小时数和第二周差不多话，是很难能确定工作量也差不多的，因为这些小时数可能是由不同的人来完成的，即在相同的时间内的完成量是有差异的。

但是评估故事点却不是一件容易的事。不同水平的人，去评估同样的一个任务，结果应该是差不多的。而事实上，评估结果又很容易受自身技术水平影响，水平高的人会评的低，水平低的人会评的高，这是最常见的一个问题：如何客观的评估一个任务的工作量？如果不考虑个人技能因素，那哪些标准又可以用来相对比较呢？代码量，还是其它？这个问题我也没想出答案，所以这种方法我没在用。

所以，看来评估是很难脱离个人因素的。无法直接计算出团队的速率，就只能分别计算每个成员的速率。每个成员自己领任务，自己做评估，优点是评估的更加精确，缺点是估算剩余工作量所需的时间变的困难。

参考文章：《Sprint规划：故事点数 vs. 小时数》

本文链接

学习笔记#1 键值对数据库

2010-05-25T17:10:00Z

1. 数据库有大量写操作时，应用键值对数据库（以下简称KV)能明显改善性能。关系数据库是靠索引来实现快速检索，如果有大量的写操作，维护索引会是笔不小的开销。

2. 使用KV时，应用程序要尽可能的避免表关联查询，比如可以用双向冗余存储关系来借代替表关联，把操作分解成单表操作。单表操作不仅查询性能飞快，而且可以容易实现数据量无限扩容。

3. KV数据库有着天生的伸缩性，相比关系数据库的群集，要简单不少。

4. 条件查询是KV数据库的弱项，需要通过建立额外的索引来提升查询速度，比如TCHDB+TCBDB的结合应用应该不错。

5. 当无法这二者之间做选择时，关系数据库和键值对数据库的混合架构一般可以解决问题，只要封装好应用程序的数据操作，隔离具体实现。

6. 常见的NoSql数据库：Raven(.NET), Tokyo Cabinet，Cassandra, MongoDB. 后两者是关系数据库和KV数据库结合文档数据库，性能虽不如KV数据库，但是查询的灵活性已经可以满足大部分的表单查询，如果首次尝试NoSql数据为，会一个不错的选择。

本文链接

SQLite数据迁移

2010-05-20T08:15:00Z

中小型项目使用SQLite做为数据库，做降低部署和维护的成本。随着日后项目不断更新扩展，SQLite可能无法应付程序的负载，尤其是写入操作较多的时候。此时就需要迁移至更高性能的数据库，比如MS SQL之类的。

在迁移过程中，除了程序上要做适当变更之外，原SQLite数据的导入也是个麻烦的问题，好在有一款专门针对SQLite导入其它数据库的工具DBConvert，支持从SQLite导入至其它多种数据库，支持定义导入列的映射规则，遗憾的是这个软件要付费购买。不过，似乎网上也有流传着不少破解版本:)。

本文链接

探讨一种在Silverlight不普及情况下的部署策略

2010-04-30T08:09:00Z

之所以要一直说这个问题，是因为现在太多的用户反馈一个B/S平台还需要安装一个几M的软件，感觉很别扭，甚至有所排斥。这个一部分是我的用户计算机水平不高的原因，另一个就是Silverllight的装机量在国内实在太少太少。如果一个
B/S产品在使用前都要下载安装一个运行时，那和C/S产品又有何区别呢？

B/S产品的优势就在于可以随时随地的访问，至于跨平台性，我想在国内是可以暂时不必考虑的。

C/S产品的主要优势还是在于性能上，如今用户体验在Web上也可以做的很好了，甚至更胜于。

而Silverlight就是两者各取一半，往好的看是两者的优点都有，往坏的看就是两者的缺点都有，很尴尬。再加上运行时的装机量不多，就更杯具了。现在很流行用Silverlight做WebGame，我这里可能要泼点冷水：我知道许多网页游戏，为了吸引用户来玩，不惜使用各种诱惑手段，像英雄救美，注册即送RMB等。然后你想想，当用户被骗进来试玩，一进页面就“当”的一声提示你要下载个6M的Silverlight运行时，相信大多数用户会立即关掉网页，并且下次不再光顾。你说这有几多杯具！

所以我觉的第一批Silverlight的网页游戏，除非游戏性做的很好，宣传力度到位，否则很难成功。当然它们也不会白做，有资金实力的人，不会在乎一开始的砸钱来积累市场经验和技术经验；对于白手起家想靠这产品翻身的，我建议要慎重考虑。

这个问题现在也同样困扰着我。所以我在上一篇文章《Silverlight产品部署策略》有提到，把Silverlight当C/S产品来卖，就是一种解决这个问题的思路。即是不把Silverlight当做RIA，而当做一个精简版的.NET Framwork，一个产品的大小就可以控制在10M以内（不包含资源，资源可以再即时下载），而且程序性能更好更稳定。

心理学中，有讲到一个“沉锚效应”，指的是人们在对某人某事做出判断时，易受第一印象或第一信息支配，就像沉入海底的锚一样把人们的思想固定在某处（想了解更多推荐看看《怪诞行为学》）。同样的，当你对用户说产品是B/S产品时，B/S就成了锚，此时让用户再下载安装一个软件，肯定排斥；而如果你一开始就对用户说这是C/S产品，C/S就成了锚，而你的产品大小都在10M以下，用户会欣然接受。

至于如何将Silverlight当C/S产品来部署，到时我会专门再写一篇文章，来介绍具体的操作以及一些开发过程中需要注意的细节问题。

本文链接

有用的文档

2010-04-29T16:33:00Z

我是个反文档主义者，最主要的原因是因为我很懒，其实是不会写。随着开发项目的越来越大，开始认识到有些文档是不得不写的：

一. 常规的有用文档

1. 记录需求的文档，一切之起源，比如Scrum中的Backlog。

2. 记录跟踪BUG的文档或工具，这点重要性勿容质疑。

3. 描述高层次架构设计的文档，虽然面对面交流比文档要好，可是对于架构这种涉及关联复杂，跨时间性长的文档，是必需要用文档描述的，随着时间的推移，人的大脑很难记住并展现软件的架构全景。

4. 任务计划/进度文档，任务的安排和分工，可视化项目的进度。

二. 非常规的有用文档：

1. 商业计划书，如果你在创业想找风投，这个就是敲门砖。

2. 产品远景规划，描述产品在将来的一个期望发展，可以时时用以激励团队，保持对目标的清晰。

3. 约定文档，团队合作在于相互协作，保持一致。一份约定文档，可以以书面的形式警惕拘束大家。一般是好的实践或不允许的实践的约定。

本文链接

Silverlight产品布署策略

2010-04-09T03:39:00Z

Silverlight产品在布署时，存在以下两个问题：

一. Silverlight运行时的装机量不足

Silverlight有个很尴尬的局面，由于Silverlight的装机量在国内不高，导致虽然是B/S产品，却几乎都要让用户使用前安装一个大几M的运行时，造成了用户的抵触心理。

解决方案：

既然没有B/S的优势，就干脆当C/S产品布署。因为Silverlight支持本地布署，原理就是将XAP文件复制到指定目录，再创建一个快捷方式来运行这个XAP文件即可（具体步骤请自行Google），这步是可以程序实现的。所以可以自己开发一个安装包，安装时做两件事：

1）安装Silverlight运行时。

2）布署XAP文件，并生成调用快捷方式。

同时在产品下载页中，我们可以先检测用户是否有安装Silverlight运行时，如果有则提示可以直接在网页中运行。

这样用户更容易接受，而且还把劣势反变成了一个亮点。

二. XAP文件太大影响加载体验

如果XAP太大也有很大的问题：

１）影响首次加载体验

２）互联网产品更新频繁，一旦更新就导致XAP文件缓存失效，需要重新下载

解决方案：

这是个纯技术问题，网络上有不少解决方案，最简单的一种做法，就是利用Siverlight自身的Reduce XAP size by using application library caching来实现分包下载，把首次不需要加载的程序集和频率更新的程序集做分包下载，其余比较稳定的程序集（如第三方控件等）就还是打包在XAP文件中，如此就可以较好的解决这个问题。

另外一个注意点是，生成XAP的那个程序集是不能被分包下载的，所以最好是另外建一个新的空项目来生成XAP。

三. 鱼翅熊掌不可兼得

杯具的是，上面两个问题的解决方案，貌似是不可以同时使用的。一旦设置了Reduce XAP size by using application library caching，好像就不能做本地布署，不过也没实验过，哪位朋友有兴趣接着研究的话，到时也请把成果告之一下。

本文链接