在很长时间里，.NET 阵营似乎一直缺乏一个被普遍使用的 ORM 数据访问框架，从最早的原生 ADO.NET 到舶来品 iBatis.NET 和 Hibernate.NET，后来又经历了 Linq for SQL 与 Entity Framework 的混战，可能是因为 Entity Framework 早期版本的模糊定位和反复变更的设计导致了它失之霸主之位，进而造就了一段百舸争流、群雄共...

IIS Express Web 服务器默认只绑定了 localhost 的主机名，这就意味着无法通过内网或其他自定义域名进行访问，可通过如下操作添加其他绑定。

首先，为什么要苦哈哈的写一个这样看上去没什么用的解析器？因为在某些 IoC 或 AOP 容器中（不幸的是我需要实现一个这样的 IoC 容器），常需要动态求解成员访问表达式的值，而解析表达式就是第一步。其实这个“作业”正是编译器技术中词法解析的简化版，自己手动撸一遍，对理解《编译原理》的前端处理技巧是一个很好的入门...

前几天和某某同学吃饭席间，他聊到每当要修改老项目中自己写的代码时就痛苦不堪，问我是不是也有同感。我觉得这应该是不少程序猿的心声，之所以会这样，大致有两个主因：

在 .NET 中主要有两种动态生成并编译的方式，一种是通过 System.Linq.Expressions 命名空间中的 LambdaExpression 类的 CompileToMethod(...) 方法，但是这种方法只支持动态编译到静态方法，因为这个限制我们只能放弃它而采用 Emitting 生成编译方案，虽然 Emitting 方案强大但是实现起来麻烦不少，必须要手动处理底层 I...

由于采用字典的方式来保存属性变更值的底层设计思想，导致了性能问题，虽然.NET的字典实现已经很高效了，但相对于直接读写字段的方式而言依然有巨大的性能差距，同时也会导致对属性的读写过程中产生不必要的装箱和拆箱。

在应用开发中，通常都会涉及各种 POJO/POCO 实体类（DO, DTO, BO, VO）的编写，有时这些实体类还需要实现 INotifyPropertyChanged 接口以支持属性变更通知，一般我们都会手写这些代码或者通过工具根据数据库表定义抑或别的什么模板、映射文件之类的来生成它们。

很多人都有搭建博客或知识库站点的想法，可自己买云服务器太不划算，部署管理也是个问题；基于免费又热门的 GitHub Pages 来搭建博客站点倒是省钱省力省事的好办法，于是上网一搜，满屏都是关于使用 Jekyll 来搭建站点的文章，这个 Jekyll 是基于 Ruby 开发的，上手得先装一大坨东西、各种啰嗦各种坑，看的一点欲望都没...