源代码下载地址:
http://download.csdn.net/source/823721

系统管理员帐号:admin,howareyou

论坛特色:

1. 简洁,清晰;
2. 自行设计的抽象核心类库, 高度可重用; 站在哲学的角度来思考如何设计一个通用的框架；
3. 简单清晰的用户、角色、权限管理体系与验证模型;
4. 高性能;
5. MasterPage母版页技术，代码界面最大限度分离；

论坛主要功能描述

• 前台：
  1. 用户注册、登陆、注销；
  2. 版块导航：显示所有的版块分组和版块；
  3. 帖子列表：显示当前版块下所有的帖子，可以区分置顶帖子、精华帖子、推荐帖子；
  4. 帖子内容：显示帖子内容；
  5. 帖子回复：显示帖子的回复列表；
  6. 添加帖子：用户添加新帖；
  7. 添加回复：用户添加回复；
  8. 精华帖子列表：显示所有的精华帖子；
  9. 推荐帖子列表：显示所有的推荐帖子；
  10. 帖子管理：具有帖子管理权限的人对帖子进行管理；
  11. 回复管理：具有帖子回复管理权限的人对帖子回复进行管理；
• 后台：
  1. 版块组管理：添加、删除、修改；
  2. 版块管理：添加、删除、修改，添加或修改时通过下拉框选择版块组；
  3. 版主管理：可以管理论坛中每个版块的版主，如添加、删除版主；
  4. 用户管理：查看用户资料、删除用户、封锁用户、解锁用户、重置密码；
  5. 角色管理：添加、删除、修改；
  默认定义如下角色：
  系统管理员、用户管理员、角色管理员、版块管理员、版主管理员、版主、所有者、注册用户、所有人；其中所有者指发帖人，回复人；另外系统管理员、注册用户、所有者、所有人是内置角色，不能修改或删除；下面分别对每种角色的含义进行说明：
  1) 系统管理员：拥有论坛所有权限；
  2) 用户管理员：拥有用户管理权限；
  3) 角色管理员：拥有角色管理权限；
  4) 版块管理员：拥有版块管理权限；
  5) 版主管理员：拥有版主管理权限；
  6) 版主：拥有所有论坛事务管理权限；
  7) 所有者：拥有对自己发表的帖子或回复的内容进行修改的权限；（此角色可以考虑禁用，出于数据真实性考虑，因为任何人都要对他或她所说的言行负责，不允许随便修改）；
  8) 注册用户：拥有一部分论坛事务，如看帖，发帖，回帖，管理和自己相关的一些帖子；
  9) 所有人：这个角色只是一个映射角色，任何登陆网站的人都自动拥有此角色；此角色可以表示匿名用户；仅拥有此角色的人一般只能看帖，不能做其他任何事情。当然如果愿意，我们也可以给它分配更多的权限，如发帖，回帖。如果这样，那就意味着运行匿名用户发帖或回帖了。
  6. 用户角色管理：对任意一个用户的所属角色进行管理（包括添加和删除用户所属角色）；
  7. 角色权限管理：分为两类进行管理；
  系统管理权限：用户管理、角色管理、版块管理、版主管理；
  论坛事务管理权限：浏览帖子、发表帖子、编辑帖子、置顶帖子、设为推荐帖子、设为精华帖子、删除帖子、修改回复、删除回复；
  因为权限分为两种，所以角色权限管理也可以采用两个界面实现。这两个界面的行就是所有角色，列就是当前权限类型下的所有权限点。
  8. 头像设置：设置用户的头像；
  9. 密码修改；
  10. 我的帖子管理：有我发布的帖子，我回复的帖子；
  
  另外，一个论坛可能还常常有星级评定，积分设置，界面管理，等等其他辅助功能。这些东西可以在日后慢慢补充。

希望能认识志同道合的朋友，呵呵。我的MSN:txh_723@hotmail.com, QQ:94388050  (我在公司只能用MSN)

两年前，我接触了.NET开源社区CommunityServer（简称CS），发现它巧妙的通过设计Groups、Sections、Threads、Posts、PostCategories、PostsInCategories这六张表，将一个社区中可能出现的所有数据都放在了这六张表中。它的设计给了我很多想法，原来数据库可以这样设计。

从那之后，我就一直致力于研究它的实现，后来我慢慢发现它还有很多不足之处，所以下定决心一定要设计出一套比它更可扩展，更高效，更抽象的一个数据库以及一套面向该数据库的抽象通用数据访问层。这样，就可以使我们以后的网站开发工作变得轻松很多，因为我们不必再去重新设计数据库表，存储过程，访问数据库的代码等。我们要做的仅仅使编写和特定业务相关的代码，以及UI实现即可。

当然，因为表越抽象，就意味着表越少，也就意味着查询时链接会越多，最终就可能会导致查询速度不快。为了避免这个问题，我在设计数据库时在性能方面画了很多时间去考虑，必要时还牺牲了一点点数据冗余换取良好的性能。使用了很多技巧。后来经过测试，在100W条数据情况下，通过一个一般复杂的SQL语句查询出200条数据，只需要大概1秒时间。所以我觉得，性能应该问题不大，总算松了一口气。

下面是这个框架的一些设计要点：
1）通过三个抽象表存放任何数据实体以及实体之间的关系；
2）通过两种扩展字段设计方式实现任何数据实体的字段扩展需要，并且扩展的字段支持数据库级别的排序搜索功能；扩展字段的添加和一般字段没有什么大的区别，仅仅只是添加了一个特性而已。
3）由于将实体与实体之间的关系进行高度抽象（最终抽象为平行和父子递归两种关系），导致数据库访问层的接口的通用性非常广泛，可以最大限度的支持各种可能出现的业务逻辑查询需求。
4）吸取了CS中的很多好的设计，如Provider模式，动态构建SQL实现自定义查询，缓存，多语言资源文件设计，自定义Url重写，Ajax功能，etc；
5）优秀的运行性能；
6）通过一个简单的文章发布系统的后台管理系统作为Demo，展示本框架的部分功能；

如何运行Demo见readme.txt

又有好长时间没有写文章了，最近几天正在思考如何利用目前CS的架构做一个网上书店。在设计书本类别、出版社、最新图书、推荐图书，等等功能时发现只要稍微修改一下目前CS中关于类别的设计就可以实现所有的功能，下面我开始慢慢分析。

研究过CS的朋友应该知道，CS中一个category(类别)是属于某一个section的，当初CS的设计者这样设计的原因我想因该主要是为了 实现某个人的blog中的文章分类或者某个人的相册中的照片分类的，没错这种设计在blog系统或者相册系统中是满足需要了，但是在一些更加复杂的应用中 比如电子商务系统中就不能满足需要了。目前CS中对section下分类的实现的致命的缺点是某个section下的所有的类别都是平等的，所以，我们就 不能对这些类别进行进一步分组，关于这个问题我记得前面也写过一篇关于分类的相关文章，那篇文章是以不改变目前CS表结构的方式实现各种分类需求。

当我的个人网站采用了当初第一篇文章中所描述的分类方法后，发现这样做虽然可以实现我要的任意功能，但是需要建很多不必要的 CSApplication，这样会导致整个网站变的臃肿，因为为了一个新的简单的分类就要去新建一个CSApplication，现在想想感觉非常不 好，尽管实现起来也比较简单的。呵呵，说实话，当初感觉还是满好的，只不过用多了，感觉就麻烦了，所以现在期望能够改进一下。

经过我这段时间的观察和思考，一般一个典型的网上书店对书本都会有以下一些分组：

1)正统归类，比如计算机图书、.Net图书、Java图书、C#类图书等，这些类别可以嵌套；
2)按出版社归类，即查询某个出版社出版的所有图书；
3)按作者归类，即查询某个作者的所有图书；
4)图书系列，每个图书系列中都有一些相关的图书，比如.Net黑皮书系列，等；

.....，还有很对你可以想到的其它分组方式。

从上面的一些实际的需求中我们可以看出，我们对一本书从不同的角度去观察它，那它就属于不同的分组。比如说，ASP.NET高级编程这本书，既属 于.Net，又属于Wrox红皮书系列，可能还属于清华大学出版社等，当我们要.Net图书时，应该可以找到它，找Wrox红皮书系列图书时，也可以找到 它，同理找清华大学出版社的所有图书时也同样可以找到它。上面的这种现象从数据库原理的角度来理解就是一个对象可以属于多个类别，一个类别下也可以包括多 个对象，即我们通常所说的多对多的关系。这个功能在目前的CS系统中已经完全实现，这点我就不多说了，如果还不清楚的，可以去查看一下数据库。

下面我说一下，在我看来应该如何合理的在目前CS的设计基础之上实现上面的需求。

前面说过，CS中某个section下所有的分类都是不能进一步分组的，就是说如果某个seciton下有5个分类，我们希望前面两个类别是对文章 进行分类的，后面三个类别是对照片进行分类的，当我们需要找出所有的文章分类，或者所有的照片分类时，目前的CS就无能为力了。我现在想想对这些分类进行 分组是多么有意义。所以，我就扩展目前的cs_PostCategories表，添加一个字段，比如Group,该字段的作用就是对某个section下 的类别进行分组。我们可以将前面所有的文章分类放在一个分组中，照片分类放在另外一个分组中，这个字段我们在上层的代码中可以设定为枚举，为各个枚举值设 置一个不重复的整数值即可，在数据库中Group字段保存的就是该整数值。好下面我谈一下添加这个字段我们可以解决什么问题。

前面网上书店对书本进行不同分组的这个需求现在就可以轻松解决了。

我们可以先预先定义很多对书本分类的分组的枚举，比如：

BookCategory:该分组下的任何一个类别表示一个一般的图书类别，比如.Net图书；
Publisher:该分组下的任何一个类别表示一个出版社，比如清华大学出版社；
Author：该分组下的任何一个类别表示一个作者，比如章立民；
BookSeries：该分组下的任何一个类别表示一个图书系列，比如Wrox系列；

好，现在我们就可以为各个类别分组添加很多类别了，这些类别还可以递归嵌套，并且我们可以很轻松的知道哪些类别是属于哪个分组，只要根据Group这个字段进行查询即可。

关于图书和类别之间的关系还是可以按照正常的方式进行关联，目前CS已经实现，对应的关系表是cs_Posts_InCategories(不知道有没有记错)。

不知道各位看官有没有清楚这样做会给我们带来什么好处？我想好处是显而易见的，就是只要添加Group这么一个字段，我们就可以实现对图书(也就是 一个Post)的任意任意归类，并对类别进行任意分组。你所需要思考的仅仅是抽象，即要从思想上意识到，并不是.Net类图书才是对书本进行分类，某个出 版社或某个作者就不是对书本进行分类了，您必须理解这些其实也是对书本进行归类，比如“推荐图书”、“特价图书”这些也是对书本进行归类，对吗？ ：）关键是你要理解这个概念。也许这也算是一种抽象吧，呵呵。

下面再以我的个人网站为例，说明一下这种归类和分组的好处：

我的个人网站中有通知、个人介绍、日志、文章、照片、作品、留言这些实体；其中，目前的需求是，文章和照片是需要分类的，类别不需要递归，只要一层即可。好，基于添加了Group字段的CS架构，我们可以按照下面的方式有效的管理所有这些实体。

1.
建立一个Section，并给管理员分配对该Section完全控制的权限，给匿名用户分配查看和添加评论的权限；

2.
为上面的每个实体定义一个枚举，比如PostType；

3.
为文章分类分组、照片分类分组分别定义一个枚举，比如PostCategoryType；

4.
添加所有的文章分类和照片分类，添加时每个分类都指定其所属的分组；

5.
接下来就可以在这个section下添加所有的实体了，一方面实体之间可以通过PostType枚举区分，另一方面，如果要查这个section下的所有 的文章类别，则只要获取某个PostCategoryType枚举下的所有分类即可。如果要查询某个类别下的所有的实体的时候，只要将该类别的ID传入数 据库进行过滤即可。这里有一个特殊的问题是，如果类别是嵌套的，比如.Net类别、ASP.NET类别、C#类别，其中ASP.NET类别、C#类别是. Net类别的子类别，现在我要查询.Net类别下的所有图书，怎么做呢？因为数据库里面没有一本书是直接和.Net类别关联的，都是和其子类别关联的。那 么是不是就只能把其下面的所有子类别的图书都找出来然后合并起来，最后返回呢？这样做也许可以，但是你一定觉得太复杂了吧，没错，肯定有好的高效率的方 法，关于如何解决这个问题，我先不说了，还是留待各位自己去慢慢琢磨吧，呵呵。不过我可以提一下，就是在cs_PostCategories表中还有一个 字段叫Path的，各位看官可以考虑利用该字段来解决我上面说的这个问题。

好了，上面我说了大致我的个人网站实现的思路，如果对具体实现感兴趣的朋友可以下载我的网站源代码，我也是支持开源的哦，因为本身自己也是从别人的开源项目中学东西呀，呵呵。

啊，没想到已经写了一个小时了，该停了，希望下次再有一些好的想法和大家交流。大家看了我的文章之后如果有意见或体会的别忘了给我留言哦！

今天这篇文章打算在一个小时之内完成。一直以来，我写的关于CS的文章都融入了我的自己的想法，这篇也不例外。今天写一下关于CS中对于各个类的命名方式，以及我们要如何根据它那些类的命名方式来推断这个类的含义，最后还写到了一些相关的面向对象的设计思想。

在CS中，如果是对某个实体类进行命名，则一般都是这样的：Group、Section、Post、User、Role、Message，等等；如 果是对某个实体的集合类命名，则为：ApplicationSet、PostSet、ThreadSet、UserSet，等等；如果是对某个管理实体的 管理类进行命名，则一般为：DataProviders、Groups、Sections、PostCategories、Roles、 Permissions，等等；如果是一些查询条件类，则为这样：ThreadQuery、UserQuery，等等。如果是一些利用Provider模 式的数据操作访问类，则一般都是以Provider结尾，比如CommonDataProvider、GalleryDataProvider，等等。

好，从上面的命名方式可以看出，CS中对类的命名方式我认为相对还是比较科学的，当我们看到一个类，如果它的名称可以代表一个实体，则它就是一个实 体类，这个类里的结构一定相对比较简单，只有一些属性和简单的方法；如果这个类的名称后缀带有“s”，那它可能就是一个管理类，它里面一定都是一些方法， 而且可能是一些静态方法；如果类的名称是以“Set”结尾，那它一般就是一个集合类，这个类一般结构最简单，它的作用就是用来存放一些查询结果。比如 ThreadSet这个类就是用来存放一些Thread实体的。而对于ThreadQuery这样的类，往往就是一些查询条件的容器类， ThreadQuery就是存放了一些查询Thread的条件信息的容器。对于以Provider结尾的类，则里面包含了一些抽象的函数或虚函数，这些函 数可以或必须被重写。这些函数的作用就是提供一系列操作实体的接口，供一些管理类调用。

上面分析了CS中一些类的命名特点以及他们通常的用途，下面我再说一下我更进一步的想法。

所谓的面向对象编程，应该是指这样一种意思：一些对象操纵者通过某种手段操纵或者直接操纵对象，如果操纵的结果比较复杂，则会把结果放到另外一个对 象中，这样我们就又可以用面向对象的方式来操纵这个“操纵结果”。也就是说，为了完成某件事情，需要有一个操作者和一个被操作者，另外还有一些操作手段和 操作结果，其实我们也可以把操作手段和操作结果也看成是一个被操作者，因为他们也是被操作者利用的一个棋子，最终也是要被操作者操纵才有意义的。所以，对 于我们来说，用面向对象的思想编程，最重要的就是要知道一个应用中有哪些操作者，哪些被操作者，哪些是辅助的被操作者，它们分别具有的职责是什么。突然记 起《UML与模式设计》一书中提到的一句话，OOA/D（面向对象分析和设计）中最重要的就是为对象分配职责。当我们要确定某个函数（职责）应该属于哪个 类时，我们要遵循的一个原则是：“将职责分配给执行该职责所必须信息的类”。我觉得这个是很有道理的，这样的原则保证了每个类中的每个函数的实现都是很自 然的，不需要额外的，牵强的去依赖于某个其他类里的某些东西。这也会加强类的封装性、内聚性。当然有时我们考虑问题时也不能这么简单，在设计时往往还要和 所要求的“高内聚、低耦合”等原则结合，最终选择一个折中的方案。

最后，我把整个CS系统中的一些最关键的类列出来，并做简单讲解，希望对各位分析CS提供侧重点。

CSHttpModule：一个自定义HttpModule，用来在一次请求的早期添加一些预处理，比如用户身份验证、权限设置，等；

CSConfiguration、SiteSettings：存放整个站点的全局配置信息；

RoleConfiguration、Role、Permission：和权限相关的一些类；

CSContext：封装一个页面一次请求过程中的所有信息；

CSCache：提供所有和缓存相关的操作；

CSApplication：封装了某个CS应用程序，如Blog、Forum，等；

CSException：代表了一个自定义异常；

Group、Section、Post、Thread、PostAttachment、PostCategory：存放所有主要的实体信息；

User：封装了当前请求过程中的所有用户信息；

SiteUrls：通过面向对象的方式为为这个站点提供所有需要用到的Url信息；

CSEvents：定义了整个站点中可能触发的事件；

IJob：定义了以后需要在网站后台定时处理的一个工作任务；

Provider：提供了一系列相关的抽象操作，每个操作完成一个特定的数据库操作任务；

好多天没写文章了，今天正好有点时间，所以就再花半个小时写一篇我最近一直在思考的一个问题。今天这篇文章的主题是，如何利用目前CommunityServer中的设计，实现一个网上书店中任意层次的类别管理功能。

先看一下一个一般的网上书店中书本的类别是如何组织的。其实很简单，就是一颗类别树，一个类别节点下面有任意多个类别子节点。那么我在考虑的问题 时，如果我们把某个类别删除了，比如删除了.Net图书这个类别，那是不是.Net图书类别下的所有子类别也要删除呢？按照以往的方式，应该是要删除的。 但是我觉得是不是不应该删除子节点，而是重新组织子节点更加合理呢？比如你可以将.net类别下的所有子类别等级上升为第一层节点。不过，不管怎样讨论这 个没有意义，因为不同的情况下有不同的需要，我们只要根据具体情况来设计就可以了。

在CS2.1中，PostCategory这个类的作用是对某个Section下的所有Post进行归类，而且从表 cs_PostCategories可以看出，归类是支持递归的，也就是说是允许类别嵌套的。虽然数据库表是设计为支持递归定义的，但是似乎没有一个模块 利用了这个功能，因为在CS2.1中所有对Post归类的地方一般都只有一层，比如随笔分类、相册中的影集，等等。所以，要真正实现对Post的递归分类 管理功能，需要我们自己写代码实现。研究过CS的朋友肯定知道Section是递归的，而且CS团队已经将Section进行了递归处理。通过对代码的研 究发现，在每一个Section中都定义了一个属性，Sections，这个属性表示当前Section下的所有子Section。而在 PostCategory这个类中却没有定义一个类似Categories的属性。所以，如果我们也要实现对PostCategory的递归处理，也可以 和Section一样，在PostCategory类中添加一个Categories的属性，表示当前PostCategory下的所有子 PostCategory。好了，只要添加这个属性即可，另外要做的事情仅仅是在获取某个或某些PostCategory时，需要为Categories 属性赋值，关于如何赋值可以参考Section是如何为其Sections属性赋值的。然后，按照目前CS提供的对PostCategory的CRUD操 作，我们就可以很轻松地对PostCategory进行递归处理了。昨天网上我基本完成了这个功能，再经过测试之后就可以整合到目前我的个人网站框架中。

我们知道，通常要递归的管理一些实体，最好的方式就是采用树状结构。像CS在管理Section时就是采用树的。所以，我们可以参考Section的树状管理代码，自己写一个用户控件，以及一个后台CS文件。这样就可以轻松对PostCategory实现递归处理。

Section和PostCategory不同的地方是，Section是对某个Post进行正统的归类，即只要有一个Post，则理论上必须使之 对应一个Section。而PostCategory则不同，因为它和Post是多对多的关系，所以，某个Post不一定必须和某个CategoryID 关联，同样如果你删除了某个PostCategory，它下面的Post是不会删除的。其实在CS中，PostCategory的功能是被设计为实现 Tag功能的。

好，到目前位置，讨论了网上书店中图书分类的功能，以及目前CS的一些设计基础。那么我们具体应该怎么来做呢？

从一个大的前提出发，因为CS架构中，任何子模块，比如论坛、博客、相册登都是以注册用户为中心的，它强调的是我发表过的帖子、我的博客、我的相册 这种概念。而一个典型的网上书店，是以书本为中心，强调的是图书展示、图书购买、订单支付这么一个流程。所以似乎和CS目前的实际不是很符合。现在想想也 是可以的。下面是我的想法：

我们可以将网上书店整个站点理解为是CS中的一个模块，相当于是一个论坛或博客或相册，只不过这个网上书店模块只能由系统管理员才可以管理。所以， 我们可以类似于某个人管理他的博客那样来管理整个网上书店。首先，我们需要为这个网上书店创建一个“网上书店分组”，相当于一个“博客分组”，然后再创建 一个“网上书店”，相当于一个“博客”。这样就创建了一个Group，一个Section了。然后通过CS现有的对Section的权限管理功能，分配系 统管理员拥有管理该Section的权限，分配一般用户查看该Section下所有Post（书本）的权限。这样就完成了系统管理员和一般注册用户的区 分。然后考虑如何实现网上书店中的所有书本类别的管理，这个刚才在上面已经说了很多了。在创建所有的图书类别时只要和网上书店对应的Section关联即 可。呵呵，是不是很简单呢，其他的应该都比较容易实现的，一个本书以及它的所有评论都可以用Post来实现，出版社、购物车、订单等可以通过自己扩展表或 者也存放在Post中，只要你开动脑子，都可以实现的。

好了，就写到这里吧，不知道各位看官有没有看懂，如果没有理解的欢迎和我交流。快吃饭去了，88

离三点钟还有半个小时，趁机把自己编程的一个小的技巧写下来吧！废话不多说了。

我们都知道在ASP里面，VBScript是嵌套在网页里面被解释执行的，也就是说代码和界面混杂在一起，所以用起来和维护起来非常的麻烦。在 ASP.NET里面情况有了本质上的变化，界面已经和代码基本没有大的关系了，一个ASPX页面对应一个CS或VB文件，可以说基本做到了代码和界面的分 离。其实微软是伟大的，它做的ASP.NET其实是一个框架，在该框架中提供了几个关键的方法，使得我们可以做到代码和界面的进一步分离，比如 CommunityServer中就很好的利用了这点。在CommunityServer中已经将ASPX文件的后台CS全部分离，转而通过用户控件或服 务器控件实现，而用户控件的后台代码都放在另外一个项目中，这样就形成了界面层中几乎只包括ASPX、ASCX等文件，而它们的后台CS文件都移到了其他 项目中，所以这就做到了进一步的分离，你说对吧？

我上面说的分离只要研究过CS的人因该都是知道的，但是下面这个技巧可能你就不一定知道了。

如果你现在要显示一个实体的详细信息，比如一篇新闻、一篇文章、一个产品，等等。你一般会怎么做呢？我想大部分人都是调用一个类似 GetObject(int objectID)的方法，然后把该Object取出来，然后你会怎么办呢？通常你会在页面上放一些Label，Literal，或者其他服务器控件之类 的，每个控件都有一个你自己命名的ID，然后你会在页面的Load事件处理函数中通过FindControl函数找到这些界面上的服务器控件，然后为其一 个个赋值。这样就达到了显示详细信息的目的。但是你有没有想过，这样做已经讲界面和后台CS代码绑定在一起了，如果你删除了某个服务器控件或者修改了它的 ID，那你的代码如果没有Try起来或者做空值判断，那肯定会出问题了。所以，为了能够既可以显示详细信息，又可以将代码和界面的耦合减到最少，我想到了 一种方法，如下：

我们可以在界面上放一个Repeater控件，在这个控件的ItemTemplate模版中将当前的Container.DataItem对象取出 来，然后，你可以通过DataBinder.Eval函数取出该对象中的任何一个字段，然后在和某个客户端标记绑定，或者直接显示出来。在后台CS文件 中，你唯一要做的只是把页面上的Repeater控件得到，然后把你通过GetObject函数得到的那个数据对象放到一个集合中，并把这个集合和这个 Repeater控件绑定即可。通过这样的方式说白了就是把显示一个实体当作和显示一个列表一样来处理。这样做有点奇怪，所以我想很多人确实不会那样去想 或做。关于前台如何显示数据，下面是一段示例HTML代码：

<%@ Register TagPrefix="CS" Namespace="NetFocus.Web.Controls" Assembly="NetFocus.Web.Controls" %>
<%@ Register TagPrefix="CS" Namespace="NetFocus.WebApplications.Article.Controls" Assembly="NetFocus.WebApplications.Article" %>
<%@ Import Namespace="NetFocus.WebApplications.Article.Components" %>
<%@ Import Namespace="NetFocus.Web.Components" %>
<%@ Control Language="C#" %>

<div class="designpattern-detail1">
    <asp:Repeater EnableViewState="false" runat="server" id="list">     
     <ItemTemplate>
         <div class="title">
             <%# DataBinder.Eval(Container.DataItem, "Subject") %>
         </div>
            <div class="subtitle">
                <CS:ResourceLiteral runat="server" ResourceName="PostDate" />
                <%# DataBinder.Eval(Container.DataItem, "PostDate") %>&nbsp;&nbsp;
                <CS:ResourceLiteral runat="server" ResourceName="Source" />
                <%# DataBinder.Eval(Container.DataItem, "Source") %>&nbsp;&nbsp;
                <CS:ResourceLiteral runat="server" ResourceName="Replies" />
                <%# DataBinder.Eval(Container.DataItem, "Replies") %>
            </div>
            <div class="body">
                <%# DataBinder.Eval(Container.DataItem, "Body") %>
            </div>
     </ItemTemplate>
    </asp:Repeater>
</div>

以上这段代码是我的NetFocus个人站点中显示文章详细信息时前台用户控件中所使用的代码。各位看这段代码的时候可以和你正在浏览的网页的布局结合起来看，就很容易懂了。

好了，不知道这样我有没有说清楚，时间正好是半个小时，呵呵。

在CS2.1中，权限是通过一个叫Section的抽象类来分配的。举例说明：博客模块中，整个网站中有一些博客分组，每个博客分组对应一个Group，由于Group没有对权限进行处理，所以每个博客分组也就无法验证权限了。其实在现实生活中也没有多大必要去控制一个博客分组的权限。在每个博客分组的下面有很多的博客，一个博客就对应一个Section，而Section是和权限相关的，所以，我们就可以控制某个博客是否允许被某个用户访问或做其它操作。那么到底一个Section是怎么和用户关联来确定该用户是否有访问该博客的权限的呢？这个关联过程比较复杂，需要用一段文字才能描述清楚。在一般情况下，某个Section的默认权限是这样和一个用户关联的：

我们知道一个用户有一些角色，这个是MemberShip就已经实现了的，不需要我多说。另外，在CS的数据库中还有一张表叫ProductPermissions，正是该表把一个Section的默认权限和一个用户的角色关联起来。该表的表结构各位看官要自己去看，我就不多说了。可以这样来理解：博客应用程序中的任何一个Section都表示一个博客，那么如果我要给一个Section设置一个默认的权限，则只要给该博客应用程序指定一些默认的权限即可。对应到ProductPermissions表就是，一个ApplicationType对应多个RoleID。ApplicationType就表示一种一用程序如博客，RoleID表示一个用户的某个角色，它来自Roles表。说到这里只是说明了一个应用程序可以和一些角色关联；还有另外一个关键点是：一个用户同时也可以属于多个角色；好，那就是说一个用户和多个角色关联，而一个Section也和多个角色关联，那只要联合这两个关联是不是就可以确定该用户是否有对某个Section操作的权限了呢，答案当然肯定的。但是，这里只是讲了大致的关联，一个很重要的细节还没有说清楚。就是说，到底怎么确定一个用户有哪些权限呢？你一定看到了在ProductPermissions表中还有另外两个字段就是AllowMask和DenyMask，是的，这两个字段就是存放具体的权限信息的。下面举一个完整的例子说明：

若一个博客应用程序中规定了这么几种具体的权限：浏览、添加、删除、修改、回复、属性设置、上传附件；另外假设当前站点中有这么几种权限：系统管理员、博客拥有者、博客编辑员、博客附件管理员、一般注册用户、所有用户；假设其中系统管理员角色、博客拥有者角色拥有所有的权限，博客编辑员拥有浏览、添加、删除、修改的权限，一般用户拥有浏览、回复的权限，所有用户只拥有浏览的权限；好，现在如果一个用户A拥有系统管理员角色，用户B拥有博客拥有者角色，用户C拥有一般用户角色，用户D拥有所有用户角色，用户E拥有博客编辑员和博客附件管理员的角色；那么就可以严格的得出以下结论：

用户A、B拥有所有的权限；

用户C拥有浏览和回复的权限；

用户D只拥有浏览的权限；

用户E拥有浏览、添加、删除、修改、上传附件的权限；

到这里，你是不是已经理解了为什么每个用户有这样的权限呢？如果是是，那恭喜你，下面一段你就不用看了，如果是否，那还必须看下面一段。

为了便于说明这种思想，我用离散数学的原理来说明。

假设有如下前提：

AA集合中包含了A1、A2、A3、A4、A5这5个元素；R1集合中包含了A1到A5这5个元素；R2集合中包含了A1、A2这2个元素；R3集合中包含了A3、A4这2个元素；R4集合中包含了A5这个元素；另外，如果还存在下面这些关系：

{AA，R1}，{AA，R2}，{AA，R3}，{AA,R4}；

{用户1，R1}，{用户2，R2}，{用户3，R3}，{用户3，R4}；

那么就可以推断出以下结论：

用户1可以访问元素：A1，A2，A3，A4，A5

用户2可以访问元素：A1，A2

用户3可以访问元素：A3，A4，A5

上面的离散数学模型其实就是CS里面的权限理论模型，A1到A5就对应一个应用程序中的5中权限；R1到R4就对应四种角色；用户1到用户3就对应三个用户；不知道我这样解释你是否可以明白，如果还不能明白，那我可能就没什么办法了，需要你在多去学学离散数学了，呵呵。

所以，在CS系统中为什么有些用户他只有一个博客，而有些用户比如系统管理员、博客管理员他拥有所有博客的管理权限。原因就是通过上面的权限控制原理来进行判断当前用户到底拥有哪几个博客，或者一个博客都没有。另外，相册模块也是一个道理。

好了，到这里为止，我都是在说明CS中是如何为某个Section应用权限的，虽然一些具体的实现代码我没有说明，但我已经说明了一个原理，一个模型，我觉得这样说明已经够了，动不动就贴代码不是我写文章的作风，具体实现代码需要你自己去看的哦！我只是希望可以帮你引导，帮你引入主动思考某个问题的轨道。

那么，从这种设计本身出发，我们可以想到什么呢？我脑子里想到的更加抽象的模型是这样的：

有一个对象，我们为了对他进行更加精确和细粒度的控制，对其划分了若干个相互独立的操作。然后将这些操作按照有一定现实意义的方式进行组合，使得组合后的那个聚合体更加有实用意义，更加能够象征某个操作者的身份。另外，对于需要操作该对象的操作者而言，为了能够有效的控制该操作者能够对该对象进行哪些操作，人们采用了这样的方法，就是将对象和某些聚合体关联，将操作者也和某些聚合体关联，这样利用集合本身的叠加作用，我们就可以灵活的控制一个操作者可以对一个对象进行哪些操作。为什么说用这样的方式控制操作权限非常灵活，因为1）对对象的细粒度操作的划分可以任意多，只要不重复即可；2）对这些细粒度操作的组合也可以任何组合；3）无论是对象还是操作者都可以以任意方式和这些聚合体进行组合；也就是说所有的关系都可以变化，只要有这个变化的需要。

上面这段话看起来似乎比较抽象，感觉自己越来越像整理设计模式的那四人帮里的那几个人了，哈哈，开玩笑的。所以，我们通过CS的这种权限控制机制可以看出当初他们的设计者的脑子里一定已经有上面我说的那种模型了，不然我想他们肯定是不会那样去控制权限的，你说呢！

好了，从他们的这个设计中，我们以后做设计应该注意些什么呢？我觉得有很多是还需要我们加强和提高的。当我们要解决一个问题的时候，我认为如果时间允许，则一定要多考虑考虑灵活性、可扩展性，不能为了光解决这个问题而去思考，我们应该想的更远，思考的更加周到。我看到一些人在设计权限的时候往往都是设置一个标志位，如0代表一般用户、1代表管理员、2代表系统管理员，然后实现权限判断的逻辑通常是这样的，如果当前用户是0，则怎么怎么样，如果是1，则怎么怎么样，如果是2，则怎么怎么样，这些判断逻辑往往都是在代码里面写死的。这样做虽然可以解决当时的问题，但是如果我现在要求有一个人不是系统管理员，但是又同时可以做0、1两个人的事，那该怎么办呢，我想按照这样的设计是实现不了了。除非你去修改代码。

最后，我希望我们中国所有的开发和设计人员，在工作和学习的过程中，能够经常去想想别人优秀设计的背后是什么，一旦你都知道了这些背后的东西，那我相信有一天你也一定可以做出老外非常感叹的设计了，难道这个不是你也想的吗？呵呵！

好了，写了差不多一个小时，该结束了，明天双休日，好好玩玩，晚安。

半夜2点，和朋友打完牌回来，洗好衣服，打开电脑，习惯性的打开我的个人网站的Solution。由于觉得以前关于一些类别的实现有些不太好，所以思考如何更好的实现类别管理。

以我的个人网站为例，文章和相册这两个模块都有类别管理，以前是通过Section表来存放类别的，即一个类别对应一个Section。后来发现，虽然这样做可以实现目前的功能，但是不太好，或者说没有真正利用CS里面的类别管理功能，比如如果我删除了一个Section，那么这个Section下的所有的Post也会删除，但实际上我们可能并不希望这样，就像博客种的日志分类，当我删除了某个日志分类之后，该日志分类下的所有日志还是在的，只不过被自动转移到了“所有分类”中。

在CS里，在同一个Section下，可以进行类别的管理，通过cs_Post_Categories表实现。比如某个人的相册中可以添加和修改影集，每个影集就是一个类别，这些类别都是在同一个Section下的；再比如，某个人的博客里，会有很多日志，日志有日志分类，一个日志分类就是一个类别，这些类别也都是再同一个Section下；经过我观察，发现现在所有的门户网站的博客中，需要管理的内容中只有一样东西是需要区分类别的，那就是日志，其他的比如照片、收藏、好友、音乐、留言、关键字等都是不需要类别；如果是这样功能的博客，那目前的CS系统也可以实现了。我们可以这样来设计，一个人的博客对应一个Section，日志、照片、音乐、留言等都只是这个Section下的不同类型的Post而已，而因为只有日志需要区分类别，所以可以在这个Section下添加一个类别，这些类别用于对日志进行分类。这样就可以实现目前大部分门户网站中的博客功能了。但是，如果有一个博客，它里面有不止一样东西需要通过类别来管理，比如日志分类、照片分类、收藏分类，那该怎么办呢？如果还是按照前面的方式来设计，由于所有这些分类都是存放在同一个Section下面，那应该怎么来区分这个类别是日志分类还是照片分类还是收藏分类呢？针对这个问题，我看了一下CS的表结构，发现同一个Section下的所有分类是不能分组的，即不可能知道这个分类是哪种分类，所以我觉得如果不增加字段是不可能实现我刚才说的那种功能了。

后来我继续研究了一下CS的功能，发现它的博客中，就只有随笔是需要分的，而对于另外一个需要分类的相册，又作为一个单独的CS应用程序设计，命名为“相册”，对单个人而言，就是我的博客，我的相册。通过这样的方式，的确可以实现随笔分类和照片分类的分开管理，因为他们属于不同的应用程序，也就属于不同的Section。

 现在开始想回来，我现在的这个个人网站，有个人介绍、站内通知、随笔、文章、相册、作品、留言这些实体。其实在极端情况下，这每个实体都是可以分类的，只要有这个需要，但实际上可能只需要文章、相册这两个实体需要分类，最多加个作品分类。因为这个是个人网站，相当于是一个博客，所以如果按照CS的架构来设计，应该把上面提到的所有实体都和同一个Section进行关联，但是就像前面提到的，对于有两个或以上的实体都需要分类的时候就不能实现了。那该怎么办呢？难道真的也要像CS那样做，就是：文章作为一个应用程序、相册作为一个应用程序、作品作为一个应用程序，并且因为不能确保其他实体以后就一定不会分类，所以也要把所有其他的实体也都作为一个应用程序管理，这样的话，我的个人网站不是成了有多少个实体，就需要建立多少种应用程序了。这样做确实是可以实现每个实体都需要分类的情况，但是不是有这个必要呢？这样做有什么好处和坏处呢？

我想至少有两个好处：

1）如果对于每个实体都通过一个应用程序来管理，那么对于这个实体来说，它可以发挥的余地大多了，该应用程序可以围绕该实体设计任意功能。比如最小的实体的应用程序就是GuestBook（留言本），对应的实体就是留言；相对复杂点的实体的应用程序就是产品网上销售系统，对应的实体就是产品；中等复杂点的实体的应用程序就是博客，对应的实体就是日志（随笔）；

2）一旦围绕某个实体的应用程序设计并实现了，那这个应用程序相当于是一个独立的模块，以后不需要做大的修改就可以直接拿过来用。比如这次我做了一个文章发布系统CS应用程序，那下次如果我在某个站点种也需要包括一个文章发布系统的，那只要直接把这个应用程序的整个工程文件拿过去编译即可。这样就可以达到极大的代码重用；虽然我们在第一次为了实现某个应用时花了较多的时间，但和后期的重用比起来还是值得的我想。

我可以想到的缺点如下：

1）当一个站点中有10种完全不相关的实体时，就必须建立10中不同类型的CS应用程序，除非你确定这10种不相关的实体种有几种实体是肯定不需要分类的而且可以和其他类别进行合并，那么你可以少建立几个CS应用程序。这样做肯定会给开发带来更多的成本；

2）是否真的有必要这样做，是不是可以考虑修改目前CS的表的结构，让它同一个Section下支持分类的分组；这个问题我现在暂时先不去研究，时间有限，而且如果表一个，对应的很多存储过程也要修改，这样可能会影响上层的很多功能。等到时间充裕的时候，我相信我们完全可以设计出比目前CS更优秀更抽象的数据库。

终于有机会可以坐下来写写设计思想类的文章了，最近一直在研究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． 我们怎样做才能接近这个目标；

待续。。。。。。

1．下面介绍一下MVC模式中的各个组成部分。

视图：

视图是用户看到并与之交互的界面。对老式的Web应用程序来说，视图就是由HTML元素组成的界面，在新式的Web应用程序中，HTML依旧在视图中扮演着重要的角色，但一些新的技术已层出不穷，它们包括Macromedia　Flash和象XHTML，XML/XSL，WML等一些标识语言和Web　services。如何处理应用程序的界面变得越来越有挑战性。MVC一个大的好处是它能为你的应用程序处理很多不同的视图。在视图中其实没有真正的处理发生，不管这些数据是联机存储的还是一个雇员列表，作为视图来讲，它只是作为一种输出数据并允许用户操纵的方式。

模型：

模型表示企业数据和业务规则。在MVC的三个部件中，模型拥有最多的处理任务。例如它可能用象EJBs和ColdFusion　Components这样的构件对象来处理数据库。被模型返回的数据是中立的，就是说模型与数据格式无关，这样一个模型能为多个视图提供数据。由于应用于模型的代码只需写一次就可以被多个视图重用，所以减少了代码的重复性。

控制器：

控制器从视图接受用户的输入并调用模型去完成用户的需求。所以当单击Web页面中的超链接和发送HTML表单时，控制器本身不输出任何东西和做任何处理。它只是接收请求并决定调用哪个模型构件去处理请求，然后用确定用哪个视图来显示模型处理返回的数据。现在我总结ＭVC的处理过程，首先控制器接收用户的请求，并决定应该调用哪个模型来进行处理，然后模型用业务逻辑来处理用户的请求并返回数据，最后控制器用相应的视图格式化模型返回的数据，并通过表示层呈现给用户。

2．上面大致介绍了比较通用的MVC模式中各个模块的功能和联系，下面我介绍一下MVC模式是如何应用在DataStructure中的。首先来看一个比较抽象总体交互图。

说明：

       上图中视图和面板等GUI就是MVC模式中的视图，工作台代表控制器，布局管理器代表模型。不过视图和面板已经被抽象化，也就是说它们并不是直接以某种可视控件的形式供其它对象使用，而是以接口的形式来向外界提供可视化元素。工作台表示控制器，工作台并不知道如何在屏幕上显示视图或面板。工作台并不关心视图或面板的显示方式，真正显示视图或面板的逻辑驻留于布局管理器中。正如MVC模式中所定义的那样，控制器从某个视图接受用户的输入并调用某个模型去完成用户的需求。布局管理器处理GUI逻辑，负责处理GUI元素的显示方式。在当前的DataStructure中，工作台和布局管理器都只有一种，即单文档界面（以选项卡的形式显示文档）。在DataStructure中典型的GUI元素（即MVC中的视图）有面板、视图、菜单、工具条、状态栏，下面我详细介绍一下其中几种元素。

视图（ViewContent）：

在DataStructure中，所有视图都实现了一个接口（IViewContent），该接口定义了所有具体视图必须要实现的操作。当前有两种类型的具体视图：文本编辑器视图和网页浏览器视图。因为所有的具体视图都实现了接口所规定的操作，所以当外界要调用某个视图所提供的功能时，只要引用IViewContent接口即可，而无需指定具体的视图的类型。视图在一个应用中能够被打开多个。

面板（PadContent）：

       和视图一样，系统中所有的面板都实现了一个接口：IPadContent，该接口的主要作用是抽象一种能提供某种特定功能的控件。面板是一种工具窗口，与视图最大的区别是一种面板在一个应用中只能被打开一个，并且不能被关闭，只能隐藏。面板一般用于显示一些辅助信息。在DataStructure中当前有文件浏览面板、动画面板、属性面板、帮助文件浏览面板。

菜单和工具栏：

       这两种