Discuz!NT+系统架构分析
discuz!、discuz!NT和discuz!X的区别
discuz!、discuz!NT和discuz!X的区别从去年开始接触discuz，当时只有php的版本，版本是7.0的，我是net技术出身。
所以一开始有排斥。
不过对于他们的前台，后台功能在使用的体验确实让人比较满意。
稍微懂一点技术和css的操作起后台并不困难。
可惜众口难调，功能不管怎么不错，毕竟不能让人真的满意。
于是开始对它开始修改。
七改八改几次后。
发现了问题。
自己都不知道改了哪些地方。
官方发布新的版本，如果你没有修改过css 或是php代码，那么恭喜你。
你可以比较顺利的升级了。
如惹不然。
你就要为升级准备加班了。
目前已经有的版本，基本php语言和net（C#）的平台。
都遵守三层的mvc结构。
discuz！，discuz！NT，discuz！X。
三个版本。
于其说是版本的进步。
不如理解为发展方向的改变。
discuz!,discuz！X都是基于php的语言。
x版更像一个多元的门户网把所有的东西进行一鼓脑的整合。
从论坛到空间，相册，再到聚合。
网站的结构和规模都越来越大。
不知道什么样的方向定位也使得许多站长非常无奈。
当然如果是新的项目，最好的选择是直接用最新的平台。
从用户体验上说，三者存在一定的差别，nt版到3.1了，支持silverlight的技术变得成熟了，加入一个特效。
就论坛而言，和discuz！没有什么非常大的用户体验差异。
discuz！X版呢由于整合的功能太多。
常常感觉不知道从哪里开始点。
怎么用这个网站。
从技术角度上说，可以说是一个痛苦的过程。
一个是升级，很可能会失败，一旦这样多数站长就不准备升级了。
就直接这样将就着。
从修改的角度看。
discuz！发展到7.2的版本，主题风格改变，如果你没有修改过功能或是样式。
那更换主题是一件相对轻松的事。
不然你又要头痛熬夜了。
如果你掌握了它的文件结构比如css和xml。
加上自己会做美工。
那你很幸运。
你可以花上几个礼拜的时间自己做一个喜欢的。
discuz！X版目前聚合首页没有模板，nt也存在这样的问题。
网站建设系统解决方案Discuz!社区动力论坛系统解决方案
--------------------------------------------------------------------------------------------------------------------------本资料由郑州网站建设E网中国（）整理编辑，未经许可不得转载。
郑州网站建设，郑州网站设计制作，郑州网络公司，网站优化，网站推广，网站搜索引擎优化请找专业郑州网站建设E网中国--------------------------------------------------------------------------------------------------------------------------一、Discuz!社区动力论坛系统简介：Crossday Discuz! Board 论坛系统(简称Discuz! 论坛，中国国家版权局著作权登记号2006SR11895)是一个采用PHP 和MySQL 等其他多种数据库构建的高效论坛解决方案。
论坛软件系统亦称电子公告板(BBS)系统，它伴随社区BBS的流行而成为互联网最重要的应用之一，也逐渐成为网站核心竞争力的标志性体现。
作为商业软件产品，Discuz! 在代码质量，运行效率，负载能力，安全等级，功能可操控性和权限严密性等方面都在广大用户中有良好的口碑。
2006年7月CNNIC 发布的最新统计表明，43.2% 的中国网民经常使用论坛/BBS/讨论组,论坛社区应用首次超过即时通讯 IM ,成为仅次于收发Email的互联网基本应用。
Crossday Discuz! Board（以下简称 Discuz!，中国国家版权局著作权登记号 2006SR11895）是康盛创想(北京)科技有限公司（英文简称Comsenz）推出的一套通用的社区论坛软件系统，用户可以在不需要任何编程的基础上，通过简单的设置和安装，在互联网上搭建起具备完善功能、很强负载能力和可高度定制的论坛服务。
discuz! 页面含义及目录结构分析
discuz!页面含义及目录结构分析2009-6-10 15:35admincp.php——后台系统设置程序文件，一般只处理菜单的显示的访问权限，不处理管理控制。
attachment——附件文件，仅仅处理附件下载的功能。
announcement.php——论坛公告的显示，一般很少改blog.php——浏览BLOG文章时候会用的，非常容易理解config.inc.php——配置论坛数据库、密码等信息，这个大家最熟悉了digest.php——论坛精华区的信息显示，不用多说了吧？discuz_version.php——论坛版本信息，用来更新用的，没有官方说明绝对不要修改faq.php——论坛帮助系统，不过我看绝对没人用forumdisplay.php——很简单，论坛主题列表的显示index.php——控制首页元素显示logging.php——登陆系统，判断用户名、密码。
mail_config.inc.php——配置论坛EMAIL功能member.php——控制会员列表显示，积分策略等等信息显示memcp.php——会员控制面板misc.php——控制评分功能、BLOG、论坛界面显示功能等等plugin.php——论坛插件，这个主要控制论坛插件的菜单的显示，一般极少修改pm.php——论坛短信息程序，控制短信息发表与浏览post.php——与viewthread.php相似，但是更多是管理帖子发表、编辑等等信息，也会有权限的控制提示redirect.php——控制显示论坛的最后发表的主题访问register.php——注册文件，同时也会控制注册的信息的合法性rss.php——RSS快速订阅，不用多说了吧？search.php——处理论坛搜索功能中的信息筛选seccode.php——论坛注册，生成验证码的程序stats.php——处理统计中的统计信息topic.php——一般无法直接访问，控制页面显示，显示主题条数topicadmin.php——控制的是管理人员的前台管理操作，如精华、置顶、高亮等等viewpro.php——处理浏览会员信息的内容显示viewthread.php——处理浏览帖子时候的帖子信息显示，例如信息、标题等等，同时也处理访问帖子的权限，如阅读权限是否足够等等。
论坛系统设计方案
论坛系统设计方案论坛系统是一种用于在线讨论、交流的平台，用户可以在论坛上发表帖子、回复他人的帖子，并与其他用户进行讨论。
为了设计一个高效、可扩展、安全的论坛系统，下面是一个论坛系统设计方案。
首先，需要确定论坛系统的功能需求。
常见的论坛系统功能包括用户注册、登录、发帖、回帖、搜索、私信等。
用户注册和登录模块可以使用常见的用户认证方式，如用户名+密码，手机验证码等。
发帖和回帖模块需要提供富文本编辑器，并支持图片、链接、表情等元素的插入。
搜索功能可以基于关键词实时搜索帖子和用户，并提供相关性排序。
私信模块可以通过建立用户之间的关注关系实现，用户可以发送私信给关注的用户。
其次，需要设计论坛系统的数据结构和数据库表结构。
论坛系统的数据结构主要包括用户、帖子、回帖、标签等。
用户表包含用户的基本信息，如用户名、密码、邮箱、头像等。
帖子表包含帖子的基本信息，如标题、内容、发帖时间等。
回帖表包含回帖的基本信息，如回帖内容、回帖时间等。
标签表用于给帖子添加标签，方便用户进行分类浏览和搜索。
在数据库设计方面，可以采用关系数据库来存储论坛系统的数据。
用户表、帖子表、回帖表和标签表可以分别建立对应的数据库表，并通过主键和外键来建立关联关系。
同时，为了提高查询效率，可以建立索引来加速常见的查询操作。
另外，为了提高论坛系统的性能和可扩展性，可以采用分布式架构。
可以使用分布式文件系统存储用户上传的图片和其他附件，使用分布式缓存来缓存热门帖子和用户数据，使用负载均衡技术来均衡请求，使用数据库读写分离来提高数据库性能等。
此外，还可以使用CDN来加速图片和静态文件的访问速度。
最后，为了保证论坛系统的安全性，可以采取一些措施。
可以通过用户登录认证、权限控制等方式来保护用户数据的安全性。
同时，对于用户发表的帖子和评论，可以设置敏感词过滤和人工审核等机制，防止违法和不良信息的出现。
此外，还需要对用户上传的图片和附件进行安全验证和过滤，防止恶意代码的注入。
BBS论坛系统
数据库表及关系建立
1.用户基本资料表 2.用户详细信息表 3.论坛文章表 4.论坛版块表 5.回帖信息表
用户基本资料表
用户详细信息表
论坛文章表
论坛版块表
回帖信息表
封装的Bean
usersBean.java userdetaiBean.java forumBean.java boardBean.java replyBean.java DB.java page.java
系统功能结构_前台功能结构
用户访问论坛首页面后，可进行查看版面 下根贴信息、查看自己发表的帖子、查看 根贴信息、用户注册等功能。用户在此 BBS论坛中通过注册成为该网站的真正用 户并成功登录系统后，可进行发表帖子、 回复帖子、查看自己发表的帖子等操作。 前台功能结构图如图下所示。
系统功能结构_后台功能结构
若用户的权限为管理员，则可进入后台， 可进行回帖的管理、版块管理和用户管理 等操作。后台功能结构图如ER图概念化地构建实体间关系的模型，这使得它 们区别于数据库模型图。ER图的理念是：项目所 有参与者能理解ER图。ER图由不同实体类型、 关系、特性和类型构成。实体是诸如用户的实际 对象，有时更抽象，但必须有业务意义。特性用 于描述实体，关系用于实体之间 （1）实体：现实世界中的事物； （2）属性：事物的特性； （3）联系：现实世界中事物间的关系。实体集的 关系有一对一、一对多、多对多的联系。
Discuz!任务系统简析 (一)帖子类任务
Discuz!任务系统简析 (一)帖子类任务
与以往版本相比，Discuz! 7.0.0 正式版的亮点之一是增加了任务系统。
任务系统常见于各种计算机软件程序和大型网游。
对于网游来说，游戏开发商为了活跃用户、提高用户与游戏、用户与用户之间的交互性而设计了任务系统，往往是大有收获;与网游不同的是，Discuz! 7.0.0 正式版的任务系统是为了活跃论坛，同时也能活跃会员，提高论坛会员的参与性、积极性，会员除了看帖、回帖，现在也可以做做任务，更有各种奖励。
无论是新会员还是潜水的老会员，都将被任务系统“钓”出水面。
下面，就对任务系统中的“帖子类任务”进行简单分析。
可以看到Discuz! 7.0.0 正式版目前开放了5个任务系统，这里只着重分析帖子类任务。
完成任务基本设置：任务名称、任务描述、任务图标、上线日期等。
帖子类任务常用于论坛举办各种重大活动、发布各种重大公告、决议事项等等，例如新产品发布、新活动上线、新版块开张、新主题策划、论坛重大调整或人事变动等等。
在2008年12月12日发布 Discuz! 和UCenter Home新版本时，康盛创想(Comsenz)公司就设置了帖子类任务“庆祝 Discuz! 和UCenter Home发布，百万金币等你来拿”。
此活动让这个任务帖子在一天之内回复达12404页，总回复124031楼，浏览量数十万。
这个案例的成功，证实了帖子类任务的作用。
中小站长对任务系统的合理运用，也能为自己的论坛带来超高的人气。
文章来源于：/article-24378-1.html。
论坛三层架构设计说明书
BBS论坛三层架构设计说明目录一、概述 (2)1、三层架构的含义 (2)2、三层架构的优势 (3)3、开发平台和支持技术 (3)二、系统设计框架 (4)1、架构设计思想 (4)2、系统设计思路 (4)三、三层架构的应用实现 (4)1、创建数据库 (4)2、创建数据访问层 (5)3、创建业务逻辑层 (7)4、创建用户表示层 (9)四、总结 (11)一、概述1、三层架构的含义三层体系架构是N层体系结构的一种特殊结构，也是最常见的一种结构。
简单地说，N层结构是指把解决方案分解到N个逻辑层中。
在一个比较复杂的项目中，把业务层分解为多个层有许多好处，如结构清晰、代码复用性强、维护方便等。
该文以网上购买服务的Web应用系统的实现为例，说明使用三层结构的技术方法和优势。
选择三层架构是因为它提供了N层体系结构的大多数优势，同时不需要花费很长时间来设计用以支持N层复杂体系结构的代码。
三层架构自下而上分别指的是业务表示层（UI）、逻辑层（DDL）、数据访问层（DAL）。
表示层主要是由窗体和用户控件组成，该层是直接面向用户的，要求设计美观大方、界面方便使用。
表示层中的业务逻辑都存储在业务逻辑层中，当用户操作界面发生请求时，由表示层调用业务逻辑层中相应的方法来具体实现。
业务逻辑层是程序的核心部分，它主要是由各种函数构成，它们集中在该层有利于模块化管理和程序复用，且能够使程序结构清晰、提高可读性。
数据访问层负责接收来自业务层的数据调用请求，该层包含数据库访问链接字符串，负责访问数据库调用存储过程，并将数据操作结果返回给业务逻辑层。
2、三层架构的优势1）扩展性强、依赖性小。
假设一个没有分层的系统各种逻辑关系紧密连接、相互关联制约、彼此间相互依赖不可替代，那么需要一旦要求改变，对系统的影响将是极为严重的，甚至是颠覆性的。
三层架构规范了各层的职责，降低了层与层之间的依赖性，大大提高了系统的可扩展性。
2）复用性强、开发周期缩短。
论坛系统组织结构与功能分析
计算机分析与设计——论坛系统分析报告学校：学院：班级：姓名：______________________学号：指导教师：____________2010年10月目录1.引言 (3)1.1开发背景： (3)2组织结构与功能分析 (3)2.2 业务功能一览表： (4)3.业务流程分析 (5)3 .1 业务总流程图 (5)3.2 各部门的流程图 (5)3.2.1会员注册流程图 (5)3.2.2 会员登录流程图 (6)3.2.3会员管理流程图 (6)3.2.4 论坛版块管理流程图 (7)3.2.5帖子发表 (7)3.2.6 帖子回复 (8)3.2.7帖子管理 (9)4．数据与数据流程图 (10)4.1整体数据流程图 (10)4.2各模块数据流程图 (10)4.2.1 管理方面数据流程图 (10)4.2.2帖子管理数据流程图 (11)4.2.3用户功能数据流程图 (11)5.系统设计 (12)5.1系统目标 (12)5.2系统构架 (12)5.3软件平台环境 (12)5.4数据库设计 (12)5.4.1用户信息表tb_user (12)5.4.2发帖信息表tb_manager (13)5.4.3用户回帖信息表tb_auther (13)5.4.4 管理员信息表 (14)6.UC矩阵图 (14)7. 论坛系统简介 (15)7.1论坛由如下功能模块组成： (15)7.2论坛页面及相关功能 (16)1.引言1.1开发背景：BBS的英文全称是Bulletin BoardSystem，翻译为中文就是“电子公告板”，是有许多人参与的网络论坛系统。
用户只要链接到因特网上，利用浏览器就可以直接使用BBS来阅读其他用户的留言和发表自己的意见。
根据The definitiveBBS list 1 999年的数据，全世界有超过40000个BBS，BBS的历史比互联网(1ntemet)要早，但发展到今天，绝大多数BBS是建立在互联网上的，BBS有自己的文化，有自己的“行话”，有自己的管理者。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
Discuz!NT 系统架构分析
前一段时间负责负责论坛的迁移工作，对其架构进行了简单的整理。
前几天看到有人说discuz的介绍很少，因此整理了一下，发布出来。
也是第一次发表文章，大侠们手下留情。
Discuz整体架构如下图所示：
横向表示同一层次中涉及的各个模块(项目)
纵向表示不同层次之间模块的关系，某些关系是如何在各层次中传递(穿越)
Discuz架构上采用了比较流行的三层架构，即表现层，业务逻辑层，数据访问层来进行设计，并结合自己的情况进行了特殊处理。
表现层：
表现层即为上图中蓝色虚线表示,主要包括:Web，Services，UI，Control。
各项目主要功能为：UI 定义各种页面基类，提供Ajax访问访问接口。
Control存放Discuz用到的自定义服务器端控件。
Services提供外部访问接口。
Discuz引入了一种模板引擎的机制，来实现表现层的多样化。
主要设计思想为：针对设计人员，提供纯静态页面，并提供了一套约定的语法和标签（具体位置在：templates）。
模板制作完成后，要进行模板导入，此时discuz会将静态模板进行解析将其转换成aspx页面，然后放到aspx/1..n下。
如果你打开这下面的文件，会发现前端只是一个字符串拼接的过程。
要进行的逻辑判断，都放到了后台代码中。
后台代码只有一份，所有的aspx 模板引用同一个后台处理类。
由此实现web表现的多样化
当用户进行页面浏览时，首先确定显示哪个模板，然后采用地址重写技术，将其转移到实际的处理文件。
在web.config配置为
可见Discuz对所有的请求进行了控制，其代码如下（以Index.aspx为例）：
首先程序会先查找Cookie，找到TemplateId，然后重定向到相应的模板文件。
综上所述：模板+重定向实现了表现层的多样化。
业务逻辑层：
业务逻辑，顾名思义就是处理与业务相关的代码。
Discuz采用的也是中小型项目的常用的“贫血模式”，即在业务逻辑层只是进行实体的获取，转发和赋值，几乎没有业务操作。
本该封装在此层的业务代码进行了分散，一部分前移至表现层（比如发帖时的加分操作，附件处理），一部分后移到了存储过程（比如发帖后更新我的发帖列表）。
注：关于贫血模式的论述详见Martin Fowler的相关著作<企业应用架构模式>等
在业务层，使用了Discuz缓存。
主要是更改了存储体，将其存储在xml中（为啥这么喜欢用xml呢，印象中它是很慢的），调用方法和通常情况下几乎无差别。
个人感觉其业务逻辑层是项目中设计最失败的地方。
拿发帖举例,如果我进行设计，我的方案可能会是这样：
时间关系，有时间再写一篇文章。
顺便说一句：如果要进行Discuz的整合，主要调用的就是此层的代码。
主要项目为：
Discuz.Forum
Discuz.Space
数据访问层：
Discuz基于商业考虑和版本限制等因素，迄今为止已有多种数据源：access，mysql，sqlserver 等。
为了实现三种数据库的接口统一，此处使用了接口和抽象类进行规范。
其类库结构如下(调用方以Post为例)：
各个数据库中的PostManage都使用DbHelper进行通用数据库的访问。
DbHelper本身并没有指定具体的数据库链接类型，参数类型，而是使用.Net自带的抽象类DbProviderFactory来创建。
具体数据库的加载要等其静态属性Provider,Factory调用时，读取配置文件，以反射形式进行初始化。
代码如下：
通过此种形式,可以实现各种数据接口的调用的统一，同时方便数据库类型的拓展。
比如要加入Oracle的支持，只需要继承IDbProvider实现OracleProvider，新的PostManage继承IDataProvider 重写部分方法即可。
而业务层（Posts）的调用通过IDataProvider接口来进行统一，避免了和数据库类型的耦合，可以在不改变业务层，表现层的代码基础上实现数据库之间的迁移。
这正是大型项目所需要的，以接口来实现层与层之间的通讯，将更多的可变因素，扩充点实现配置化。
其他子模块的介绍
1.配置
对配置的管理，小型项目可以直接使用web.config，中大型项目一般使用自己的配置解
决方案。
原因是：
1. 中大型项目配置文件过多，直接使用web.config来会造成其体积过大
2. web.config直接使用字符串进行读取不方便，
试着比较一下：
ConfigurationManager.AppSetting[“SiteName”];
3. 每次都需要进行类型转换
Discuz实现了自己的配置类，其类结构如下(以Email为例)
IConfigInfo为空接口，没有定义任何方法，主要是方便DefaultConfigFileManager传递，方便以后扩充。
对配置文件的解析也没有使用.Net自带的接口，而是重新定义了接口，同时使用了xml 反序列化实现配置文件的加载和类型转换。
代码见: DefaultConfigFileManager.DeserializeInfo
比较疑惑的是这个项目中某些类给出了实现，却没有发现调用。
可能是兼容或者扩充问题留下的，谁对这方面了解的，也可以跟帖说下。
这些类有：ConfigProvider，IConfigFileManager
2.数据库表的设计
数据库设计中有两个引人注意的地方：
1.主题表分离
如果由我们来设计主题表和回帖表，通常的做法是如下。
这样在获取主题列表时，直接使用分页算法提取Topics；查看某一帖子时，还需要对Topics，Posts 进行jion链接。
此种设计的缺陷为：
1.Topics表存储Content的内容，其体积将会很大，对大体积表进行分页，性能很慢。
2.显示Posts内容时将进行join操作，损耗性能
而Discuz的做法是进行如下设计。
将Topics里的Content拆分到Posts中去，同时Topics的主题帖也作为回帖放置到Posts里面，这样就解决了上面我们提出的两个问题。
这是典型的违反数据库设计范式以换取更好性能的示例。
2．对Posts表进行水平拆分
原来以为每一百万帖子，discuz会自动进行拆分，后来发现在discuz后台能够进行设置，手动进行分表，discuz建议每30-50万帖子进行一次拆分。
进行拆分后，每个表的体积将会减少，保证了查询的效率
Discuz的整体架构还有很多其他值得细说的地方，例如插件、扩展等，这些需要感兴趣的人自己一一去研究，在此就不多讲了.。