终于有机会可以坐下来写写设计思想类的文章了，最近一直在研究CommunityServer（以下简称CS），对某一样东西接触多了总会有一些感受，所以想写下来和大家分享：）。另外，补充一句，由于这篇文章偏重的是设计想象，所以希望各位看官能耐心点，尤其是后面部分，如果看了之后感觉在浪费时间，那看都看了，下次就不要再来看了，呵呵。

 自从CS出来以后，外界已经有很多人都在对CS进行学习和研究。我看到有很多网站直接拿CS作为自己的社区管理系统，但是我发现真正从核心级别研究CS的人不多，很多都只停留在表面，所以不能充分利用它的设计思想及源代码。下面我说一下我在学习CS过程中的一些感受和体会：

1． 一个好的系统需要有一个抽象的可扩展的核心；

假设D依赖于C，C依赖于B，B又依赖于A。好，在这种情况下，如果A、B、C、D

是一个软件中的必要组成部分，那么，我认为应该让A设计的最好、最抽象，其次是B、C、D。因为如果你把A设计的抽象而又有扩展性，那就可以在她基础上生出一个很优秀的B，因为B可以不受约束的表现出任意形态，同理C、D也是一个道理。对于CS系统，A对应的是数据库中的几张抽象的表（Groups、Sections、Posts、Threads），B对应的是Components项目中的几个抽象的类（Group、Post、Thread、Section），C对应的是整个系统中某个子系统（如论坛、相册等）。关于这四张表设计的如何抽象如何优秀，网上已经有很多这方面的资料了，比较有名的有宝玉的一些文章。我在这里也冒昧谈一下我的理解。

Group：代表了现实生活中的一些实体所属的大类。

Section：代表了现实生活中一些实体所属的从第二层类开始的所有小类（可以嵌套）。

Post：代表了现实生活中一些实体，可以嵌套。

Thread：不代表现实生活中的任何实体，是一个纯粹抽象的概念，是对相关Post的统计。

它们之间的关系如下：

通过一个可以唯一标识Group的东西，比如GroupID可以获取所有的Section，类似的通过一个SectionID可以获得所有的Post，通过一个ThreadID可以获得所有相关的Post，通过一个PostID可以获得所有的子Post。

好，将上面提到的几个概念进行组合，我们可以很方便的构建出一些日常生活中经常接触的系统。先说一下通过这四个概念可以做什么事情：

我们有时候经常需要对现实生活中的实体进行归类，而且复杂的时候往往类别都是嵌套的。另外我们有时候往往会对某个问题进行讨论或共享或公布，如在CSDN上发起一个帖子，后面的人对这个帖子进行讨论；或者网易的新闻发布员在网站上发布了一条新闻，很多人过来阅读并进行评论；或者亚马逊网站的网站维护相关人员上架了某个商品，很多人购买并发表评论；或者阿里巴巴系统中的某个会员（即公司）新上架了某个最新产品，其他会员查看其特点并可能会寻盘以了解该产品的详细信息。再或者你给某个留言板管理员留了言之后他对你的留言进行回复；等等。

所有上面提到的例子其实都可以用上面所说的这四个概念或其中某几个概念来实现。

以下举例说明：

1） 论坛系统

论坛主要由版块组、版块（一个版块可能还有子版块）、帖子、帖子的回复这四种概念组成；所以，很明显，我们可以用Group表示版块组、Section表示版块、Post表示一个帖子或回复、Thread存放了某些相关子帖子的所有统计信息。

2） 博客系统

一个典型的博克系统由博客分组、某个人的博客、某个人博客中的一篇随笔或日志、随笔或日志的评论或引用；所以，我们也可以像论坛那样用Group表示博客分组、Section表示某个人的博客、Post表示一篇随笔或日志或其评论、Thread存放了一篇随笔及其所有评论的统计信息。

3） BToB系统

一个BToB系统其实是一个企业交流的平台，它往往有很多会员（公司）、每个会员可以发布自己的介绍信息、产品、供应信息、求购信息、新闻通告、招聘信息等。产品，供应信息，求购信息，新闻等内容一般都属于某个具体的类别，而且该类别往往还属于一个更大的类别。我们可以用Group存放一些最大的类别，Section存放除最大类之外的所有子类别，Post存放产品、供应信息、求购信息、新闻等，Thread存放一些统计信息。另外，一个公司的产品不仅属于某个产品类别，还可能属于某个公司自己管理的产品系列，这中情况其实是很常见的，比如有一本书《.Net 框架程序设计C＃版》，它最"正统"的类别是C＃类图书，但是呢，它又同时是黑皮书系列。所以，用抽象的思维来理解就是，一个实体从不同的角度去理解，它就是不同的东西，也就是说属于不同的类别。好，那么我们该把产品的系列如何看待如何存放呢？看了CS，我发现它还有一张cs_Post_Categories表，还有一张cs_Posts_InCategories表，我到目前为止还没有去细看它的用处，但是从这两张表的结构来看，应该可以满足刚才我说的情况。我们可以把产品的系列放在cs_Post_Categories表中，然后用cs_Posts_InCategories这张表来建立产品和产品系列的关系。那么，我们是否可以把产品系列也放在Post表中呢？我觉得是可以的，因为产品系列在这种情况下也可以理解为一个实体，并且这个实体和多个产品实体相关。所以，我们可以把产品系列也放在Post表中，然后像管理产品那样对其进行管理。那么，我们该如何为产品和产品系列建立关系呢？有一个办法可以做到，就是利用目前CS系统中的扩展属性ExtendedAttribute，我们为某个产品实体添加一个扩展属性，比如叫SerialID，该属性和SectionID属性的作用一致。但是问题是SectionID在数据库中有一个明确的字段，所以可以直接作为条件进行SQL查询，而SerialID在数据库中并不存在一个与之对应的字段，那我们就不能直接通过SQL语句查询出某个产品系列的产品了。这的确是一个问题，从更抽象的角度来看，只要是通过ExtendedAttribute的方式新增的字段都不能作为SQL查询条件进行查询。我们如果要得到期望的结果，只能先将没有过滤过的产品都查询出来，然后在内存中人工对其进行过滤以返回正确的结果。所以，结论就是，通过像CS新建表的方式，可以实现这种情况，而且查询起来也比较方便，效率高，但是，目前表中的字段似乎设计的还有点问题，因为CategoryID是和某个SectionID关联的，而不是和一个更抽象的字段关联，CS的设计人员可能仅仅考虑到了某个实体一定属于某个Section的情况，而没有考虑到一个产品不属于任何一个Section的情况；通过扩展属性的方式，虽然可扩展性比较好，但是由于数据库中没有可以直接利用的字段，所以查询起来比较困难。这两种方法，都可以尝试一下。

4） 电子商务系统

一个电子商务系统的前台部分主要由商品类别、商品、商品的评论、购物车、订单系统组成。对于商品类别、商品、商品的评论直接可以套用上面的四个概念，对于购物车，因为一般购物车中的内容都是临时的，所以不宜存放在Post表中，可以按照一般实现购物车的方式来实现，比如通过为每个用户创建一个Session、Cookie、一张临时表中的某几条商品记录，等。对于订单，一旦用户下了某个订单，就应该把这个订单及其明细信息存放到某个物理位置，如数据库，XML文档。所以，我们也可以考虑将订单及其明细信息存放在Post表，把明细信息看作是订单主记录的一些回复或评论。也许你可能会想订单又没有类别，那以后该如何去访问某个人的某张订单的信息及其明细信息呢？我觉得可以这样理解：如果一张订单有4件商品，那么在数据库Post表中存5条记录，第一条记录存放订单记录本身，另外4条存放明细信息，这5条记录的ApplicationPostType（这个字段表示某个子系统中某种类型的实体）应该设置为相同，然后将后面4条记录的ParentID设置为第一条记录的PostID，通过这样的方式，我们就可以存储一张订单了，并且也已经建立了订单信息及其明细信息的关系；这样，如果我们现在要找某个人的所有订单，则可以将ApplicationType、UserID、ApplicationPostType作为参数进行查询，即可获得所有订单信息及它们的明细信息，获得原始数据之后上层可以用面向对象的类来进一步组织这些信息，比如你可以设计两个Order、OrderDetail类来存放订单和订单明细信息，以方便上层访问。如果我们仅仅只要获得某个人的订单列表，不需要获取订单的明细，则只要将 ApplicationType、UserID、ApplicationPostType、ParentID为空这四个条件作为参数查询，返回的所有Post就是所有的订单了，不包括订单明细。最后，如果要获取某个人某个订单的信息，则只要将PostID作为参数，再用一些SQL技巧就可以获取这个订单的所有相关记录了。

5） 信息发布系统

信息发布系统就相对简单了，一般的信息发布系统都只有一层类别，则给予这样的情况，我们就没有必要使用Group，因为Group只有在至少有两层类别的情况下才用的着。我们可以将一个信息类别看作是一个Section，一个信息看做是一个Post。当我们要查找信息发布系统中的所有的Section时，直接将ApplicationType作为参数进行查询即可。另外，如果要获取某个信息类别下的所有的信息，则只要将某个SectionID传入即可。最后，关于信息的评论就不多说了，和上面的系统类似。信息发布系统这样应该就可以存放所有主要内容了。

6） 留言系统

这个是最简单的例子了，因为一般一个留言板中的留言没有大类，也没有小类，只有留言和回复（可能一条留言有多个回复）两种信息。那么这种情况该如何处理呢？其实很简单：从现实的角度出发，我们肯定不需要用到Group、Section这两个概念，应该只需要用到Post这一个概念即可。即我们可以把所有的留言及其它们的回复都放在Post表中，当我要查询所有的留言时，只要将ApplicationType、ApplicationPostType，PostID为空这三个参数就可以获取了，要查询某条具体留言及其回复则只要传入PostID即可。

2． 让我们来想想为什么人家会想到那样去设计；【注：上面的可以不看，但下面的一定要看哦！】

有很多人可能很少像我这样提这个问题，其实，这个问题非常重要，我到现在为止还不知道这个问题的答案，如果我知道，那我的水平就和CS的核心架构师的水准差不多了，你说呢？呵呵：）但是，我认为，我们从他们的设计结果里面可以体会出一些他们当初设计这四个概念时的思维场景。下面是我可以想象到的思维模拟过程：

我现在要做什么？

一个社区系统。

我想做到什么样的程度？

最好是可扩展性很好的那种，很帅的那种，以后维护很方便的那种。

我要不要对每一个实体都建一张表？

肯定不想这样，不然以后工作量不是很大。

那如果不建表该怎么表示所有可能出现的不同的信息呢？

我需要再思考，但是我坚信一定会有结果的。

和女朋友吃完饭回来后，开始思考的过程（请各位看管不要闲罗唆，呵呵）：

我现在要想一种解决方案，通过这个解决方案我可以轻松的扩展我的Web系统。根据我以往的经验，要知道两样东西的关系必须要先知道这两样是什么东西，要知道这两样是什么东西必须先明确这两样东西的数据结构，要知道这两样东西的数据结构需要深度分析这两样东西在现实生活中体现出来的特征。但问题是我现在面对的东西似乎太多，比如有书本，有留言，有回复，有电影，有新闻，等等等等。那该怎么办呢？什么怎么办，都想到这里了当然还要想下去的了！对了，老师好像曾经教过我，白熊和黑熊都是熊，也就是说它们都属于熊类，但是老师好像没有教过我所有上面这些东西都是什么。嗯，那我该怎么办呢，我想这个一定是老师可能也不知道的，或者没去思考过的，或者他认为这些根本就是完全不相干的东西。那如果我想出来了不是比老师更厉害？呵呵，是的！我一定要多想想，反正还有时间，技术总监给我很多的时间去思考设计的，没坏处！再回忆一下，我的目标是什么？是用某种抽象的东西来尽可能表示现实生活中多的东西，如上面想到的那些。因为只有这样我才可以在以后用一样的代码，一样的逻辑去处理所有这些现实生活中的东西以及它们的关系，哇，好像难度很大，估计老师们肯定不会这样去思考的，因为他们只会把一些看上去最正统的理论的教给学生，最离谱的最难以理解的可能就作为星号章节留作学生自学或作为思考题了。唉，对了，以前好像某个人对我说起过，任何事情如果你可以想出解决方案，就说明它的某种特征或规律被你发现了，然后你找到了一种方案可以符合这件事情的特征和发展规律，并且可以按照它的发展方向控制它，拥有它。我学过数学，记得小学时常有这样的题目，有100、120、160、200四个数字，要求它们最大的公约数，我很容易就可以答出来，看看就知道，就是20嘛！那么我那个时候究竟是怎么答出来的呢？好像有些记不大得了，可能是猜的，也可能是用超快的正统的逻辑推理计算出来的，也可能是条件反射没经过大脑得那种，也可能是老天告诉我的，呵呵。不管怎么答出来的，在我现在看来，通过逻辑推理就可以找出答案。即找出每个数的所有可以被整除的数，然后取这些数中最大的公有的那个即可。嗯，我是否可以从这个例子里面得到些有意义有价值的参考信息呢？让我再想想，唉，好像有了，如果那是我是用逻辑推理得出答案得，那么我那个时候的思维肯定分为两个过程：1）理解了最大公约数的含义；2）找到了一个可以求最大公约数的方法。这个思维过程从更抽象的角度出发，是不是可以理解为：要解决一个问题，需要先知道这个问题的特征及规律是什么，然后在符合它特征和规律的基础上施加各种外在的因素去合理的利用它，然后把利用后的好处作为我们自己的财富。那我现在也用这种理论去研究一下刚才我遇到的问题试试吧！要将一个Web站点中常出现的所有主要的实体抽象为一样或几样典型的东西，通过刚才想那个最大公约数的问题，再回过头来想这个问题好像不是那么没有立足点了，似乎也是和求最大公约数差不多耶！首先，如果是一个论坛的帖子，那么有标题、内容、回复集合，发帖时间，发帖人，是否置顶等；如果是相册中的一张照片，那么有标题，描述，评论集合，照片地址，点击查看次数等；如果是一样商品，那么有名称、详细信息、规格、价格、评论集合、上架时间、厂家信息、库存数量等；把所有这些东西都列出来，在用人类独特的观察事物总结抽象能力，就可以找出很多共同的特征。我暂时就把这个特征命名为Post吧，这个名称是什么不重要，因为它只代表了一个概念的载体。总结后，发现这个Post应该有名称、描述、诞生时间、被关心次数、可以归为的正统的一个类别、它的创造者、它的本质类别、由它而引发出来的所有相关信息、其他任意多的额外特性。嗯，暂时好像只能考虑到这些了。哇，真开心，一下子找出这么多的"公约数"，估计以后一定发了，呵呵。不过，现在离革命成功还早，我要继续思考。不过今天不早了，我要先休息，补充点脑细胞，明天再想，待续。。。。。。

3． 我们怎样做才能接近这个目标；

待续。。。。。。