http://feed.cnblogs.com/blog/u/12973/category/178306/rss2012-05-27T20:32:55Zfeed.cnblogs.comhttp://www.cnblogs.com/JeffreyZhao/archive/2010/03/09/sharding-by-id-characteristic.html

假如您有一个应用程序，随着业务越来越有起色，系统所牵涉到的数据量也就越来越大，此时您要涉及到对系统进行伸缩（Scale）的问题了。系统的扩展方式往往分为“向上伸缩”和“向外伸缩”两种，而从“硬件成本”或是“系统极限”的角度来说，“向外伸缩”一般都会优于“向上伸缩”，因此大部分上规模的系统都会在一定程度上考虑“向外”的方式。由于许多系统的瓶颈都处在数据存储上，因此一种叫做“数据分片（Database Sharding）”的数据架构方式应运而生，本文便会讨论这种数据架构方式的一种比较典型的实现方式。

2010-03-09T13:51:00Z2010-03-09T13:51:00ZJeffrey Zhaohttp://www.cnblogs.com/JeffreyZhao/假如您有一个应用程序，随着业务越来越有起色，系统所牵涉到的数据量也就越来越大，此时您要涉及到对系统进行伸缩（Scale）的问题了。系统的扩展方式往往分为“向上伸缩”和“向外伸缩”两种，而从“硬件成本”或是“系统极限”的角度来说，“向外伸缩”一般都会优于“向上伸缩”，因此大部分上规模的系统都会在一定程度上考虑“向外”的方式。由于许多系统的瓶颈都处在数据存储上，因此一种叫做“数据分片（Database Sharding）”的数据架构方式应运而生，本文便会讨论这种数据架构方式的一种比较典型的实现方式。http://www.cnblogs.com/JeffreyZhao/archive/2009/10/14/aspnet-routing-design-ideas-and-patterns.html

Route组件虽然可以说是ASP.NET的“门户”，不过至今为止似乎都被微软当作是二等公民。可能是由于自带的Route类功能已经太强，微软官方或社区内都不太关注RouteBase的扩展。不过有一点是正确的，那就是在大部分情况下的确没有必要去扩展RouteBase。事实上，我构建过不少RouteBase类，不过除了DomainRoute之外，其余的都被我放弃了，例如在大半年前写的《请别埋没了URL Routing》中所提供的FormatRoute，在MvcPatch中也已经有了更好的替代品（过几天便会谈到这一点）。

2009-10-14T01:46:00Z2009-10-14T01:46:00ZJeffrey Zhaohttp://www.cnblogs.com/JeffreyZhao/Route组件虽然可以说是ASP.NET的“门户”，不过至今为止似乎都被微软当作是二等公民。可能是由于自带的Route类功能已经太强，微软官方或社区内都不太关注RouteBase的扩展。不过有一点是正确的，那就是在大部分情况下的确没有必要去扩展RouteBase。事实上，我构建过不少RouteBase类，不过除了DomainRoute之外，其余的都被我放弃了，例如在大半年前写的《请别埋没了URL Routing》中所提供的FormatRoute，在MvcPatch中也已经有了更好的替代品（过几天便会谈到这一点）。http://www.cnblogs.com/JeffreyZhao/archive/2009/10/13/my-view-of-nhibernate-4-interceptor.html

之前谈了NHibernate的几个方面，似乎抱怨的居多，不过这次我想谈一下我对Interceptor的感受，则基本上都是好话了。这并不一定是说Interceptor设计的又多么好（事实上它使用起来还是挺麻烦的），但是这的确也是我认为NHibernate超越LINQ to SQL，尤其是Entity Framework的又一个重要方面——因为Entity Framework本身也已经不差了。更重要的是，Interceptor机制让我得以实现我“理想中的”数据访问功能。当然现在只是浅尝辄止一番，我打算以后再慢慢地，详细地谈谈我所满意的“数据访问层”设计。

2009-10-13T05:45:00Z2009-10-13T05:45:00ZJeffrey Zhaohttp://www.cnblogs.com/JeffreyZhao/之前谈了NHibernate的几个方面，似乎抱怨的居多，不过这次我想谈一下我对Interceptor的感受，则基本上都是好话了。这并不一定是说Interceptor设计的又多么好（事实上它使用起来还是挺麻烦的），但是这的确也是我认为NHibernate超越LINQ to SQL，尤其是Entity Framework的又一个重要方面——因为Entity Framework本身也已经不差了。更重要的是，Interceptor机制让我得以实现我“理想中的”数据访问功能。当然现在只是浅尝辄止一番，我打算以后再慢慢地，详细地谈谈我所满意的“数据访问层”设计。http://www.cnblogs.com/JeffreyZhao/archive/2009/09/13/detect-internal-members-in-libraries.html

两个星期前我写了一篇文章谈到一个现象（或是感觉）：我发现“类中的internal成员可能是一种坏味道”，原因在于违反了“单一职责”原则。然后谈了一般情况下遇到这种情况时一种可用的重构方式之一。结果自然是有人同意有人反对。不过刚才我忽然想到，不如检查一下微软的框架中internal成员的情况吧。微软最近几个框架都公开的源代码，社区反响不错，应该较为值得参考。

2009-09-13T15:17:00Z2009-09-13T15:17:00ZJeffrey Zhaohttp://www.cnblogs.com/JeffreyZhao/两个星期前我写了一篇文章谈到一个现象（或是感觉）：我发现“类中的internal成员可能是一种坏味道”，原因在于违反了“单一职责”原则。然后谈了一般情况下遇到这种情况时一种可用的重构方式之一。结果自然是有人同意有人反对。不过刚才我忽然想到，不如检查一下微软的框架中internal成员的情况吧。微软最近几个框架都公开的源代码，社区反响不错，应该较为值得参考。http://www.cnblogs.com/JeffreyZhao/archive/2009/08/28/unit-test-protected-method.html

protected是一个有趣而有用的修饰符，它把方法的访问成员严格限制在自身或自己的子类身上。换句话说，在使用过程中，protected成员对外部是开放的（因为其他类可以通过继承来使用该成员），又是封闭的（不是自身或子类的一切成员都无法访问）。而对于单元测试来说，protected成员又是尴尬的，因为它的“开放”意味着我们必须对它进行单元测试，而“封闭”又阻碍了我们在单元测试中涉及protected成员。

2009-08-28T09:33:00Z2009-08-28T09:33:00ZJeffrey Zhaohttp://www.cnblogs.com/JeffreyZhao/protected是一个有趣而有用的修饰符，它把方法的访问成员严格限制在自身或自己的子类身上。换句话说，在使用过程中，protected成员对外部是开放的（因为其他类可以通过继承来使用该成员），又是封闭的（不是自身或子类的一切成员都无法访问）。而对于单元测试来说，protected成员又是尴尬的，因为它的“开放”意味着我们必须对它进行单元测试，而“封闭”又阻碍了我们在单元测试中涉及protected成员。http://www.cnblogs.com/JeffreyZhao/archive/2009/08/28/virtually-necessary-members.html

这是一个由来已久的讨论，由于Java默认所有的方法都是可以被override的（除非手动写成final），因此从C#语言设计起初就有此番争论，甚至让Anders都出来解释了一下。最近又有人在讨论这方面话题了，虽然我的看法并没有超出这些人所涉及的范畴，但是我还是打算谈一下我的理解。退几步说，就当补充一些“实例”吧。

2009-08-28T02:56:00Z2009-08-28T02:56:00ZJeffrey Zhaohttp://www.cnblogs.com/JeffreyZhao/这是一个由来已久的讨论，由于Java默认所有的方法都是可以被override的（除非手动写成final），因此从C#语言设计起初就有此番争论，甚至让Anders都出来解释了一下。最近又有人在讨论这方面话题了，虽然我的看法并没有超出这些人所涉及的范畴，但是我还是打算谈一下我的理解。退几步说，就当补充一些“实例”吧。http://www.cnblogs.com/JeffreyZhao/archive/2009/08/27/more-on-bad-smell-of-internal-members-in-public-classes.html

上一篇文章里我讨论了一个类中internal成员可能会造成的坏味道，并且认为如果您的类型中出现了这个情况，可能就值得检查一下设计上是不是有问题了。文章中我提出了三种可能出现internal的情况，其中两种争议不大，不过对于“public类中是否应该出现internal成员”这一点似乎引起了一些争议。从评论中发现，讨论的一部分焦点并不是我的本意，这可能是我前文描述地较为简单而造成的，因此我现在对于这个方面再进行略为详细的探讨。

2009-08-27T02:49:00Z2009-08-27T02:49:00ZJeffrey Zhaohttp://www.cnblogs.com/JeffreyZhao/上一篇文章里我讨论了一个类中internal成员可能会造成的坏味道，并且认为如果您的类型中出现了这个情况，可能就值得检查一下设计上是不是有问题了。文章中我提出了三种可能出现internal的情况，其中两种争议不大，不过对于“public类中是否应该出现internal成员”这一点似乎引起了一些争议。从评论中发现，讨论的一部分焦点并不是我的本意，这可能是我前文描述地较为简单而造成的，因此我现在对于这个方面再进行略为详细的探讨。http://www.cnblogs.com/JeffreyZhao/archive/2009/08/26/internal-member-is-bad-smell.html

最近除了搞ASP.NET MVC之外，也在思考一些编程实践方面的问题。昨天在回家路上，忽然对一个问题产生了较为清晰的认识。或者说，原先只是有一丝细微的感觉，而现在将它和一些其他的方面进行了联系，也显得颇为“完备”。这就是问题便是：如何对待类中internal成员。我现在认为“类中的internal成员可能是一个坏味道”，换句话说，如果您的类中出现了internal的成员，就可能是设计上的问题了。

2009-08-26T08:54:00Z2009-08-26T08:54:00ZJeffrey Zhaohttp://www.cnblogs.com/JeffreyZhao/最近除了搞ASP.NET MVC之外，也在思考一些编程实践方面的问题。昨天在回家路上，忽然对一个问题产生了较为清晰的认识。或者说，原先只是有一丝细微的感觉，而现在将它和一些其他的方面进行了联系，也显得颇为“完备”。这就是问题便是：如何对待类中internal成员。我现在认为“类中的internal成员可能是一个坏味道”，换句话说，如果您的类中出现了internal的成员，就可能是设计上的问题了。http://www.cnblogs.com/JeffreyZhao/archive/2007/06/23/793756.html

http://media.joyent.com/JHoffmanRailsConf-May2007.pdf 这是今年Rails大会上的一个报告。虽然讲的是RoR应用程序，但实际该报告里包括了许多其他方面要素的阐述，例如操作系统，硬件配置等等。对于要构造大型网络应用的人来说是一个不可不读的文档。

2007-06-22T22:31:00Z2007-06-22T22:31:00ZJeffrey Zhaohttp://www.cnblogs.com/JeffreyZhao/http://media.joyent.com/JHoffmanRailsConf-May2007.pdf 这是今年Rails大会上的一个报告。虽然讲的是RoR应用程序，但实际该报告里包括了许多其他方面要素的阐述，例如操作系统，硬件配置等等。对于要构造大型网络应用的人来说是一个不可不读的文档。