【毕业学位论文】（Word原稿）基于JSP,JAVA博客网站设计与开发毕业论文范文

目录 目录 . I 摘要 . 言 . V 文献综述 . 错误 !未定义书签。 第 1 章 绪论 . 1 第 1 节 背景 . 1 第 2 节 研究的目的与意义 . 2 第 2 章 设计简介及设计方案 . 3 第 1 节 设计原则 . 3 第 2 节 运行架构 . 3 第 3 节 设计方案 . 4 第 3 章 相关技术介绍 . 5 第 1 节 介 . 5 第 2 节 起源和背景 . 6 第 3 节 述 . 7 第 4 章 需求分析 . 8 第 1 节 注册博友 . 8 第 2 节 普通用户 . 9 第 5 章 系统架构设计 . 11 第 1 节 系统架构说明： . 12 第 2 节 . 12 第 3 节 实现 . 18 第 4 节 实现 . 20 设计结果及对设计结果的分析 . 25 全文总结 . 28 致谢 . 30 参考文献 . 31 摘要 越来越多的网络用户希望能够在网络平台上更多地展现自己的个性，更方便地与他人互动交流 ，拥有一个自己独立的空间 ， 随着 代的到来，一个新的概念出现了 博客。 首先介绍了 博客 网站设计的意义和背景，主流 博客 网站的主要功能 。 重点介绍了基于 构的博客网站设计方案，实现的主要功能 。 其次， 重点讲述了博客网站的业务 逻辑层和持久层的设计与开发过程中所涉及的技术 及开源 框架。 系统 如何 以 架为核心，向下整合 持久层访问 ， 向上整合 清晰的 式控制， 怎样 划分应用的层次。 简述了页面的请求的分发 及流程 。 最后对 站开发中所碰到的一些问题， 并 针对这些问题提出一些解决方案 ，最后 对系统性能作出 一些 简要评估 ，阐述了一些 个人 想法。 关键词 : 博客 ， to in a of we of of of We of is on 2in is we of of in of We to be to to to to VC up to of We of of we of on of is a on in 言 本文介绍了 基于轻量级 发博客网站。同时利用 框架整合开发 。本文主要分为七章。 第一章主要介绍了进行 博客网站 的背景及意义。 第二章对 博客网站设计方案 做了简要介绍。 第三章介绍了 博客网站的需求分析 。 第 四 章详细介绍了 系统的架 构设计，并详细讲述了通过 架， 向下整合 行持久层访问 ，利用 式隔离 业务逻辑层与具体持久层，向上整合 清晰的 式构建系统 。 第 五 章简 单 讲述了系统设计时遇到的问题及解决方案，另外对系统的性能作了一个简要 的 评论 及设计结果和设计结果分析 。 第 六 章对全文所使用的方法、结果以及目的和意义做了全面的总结，展望术在 的一些应用。 第 1章 绪论 第 1节 背景 商业网 站设计的主要目的一般是通过网站的推广，实现更多网络用户的关注，从而吸引更多的企业用户投入更多的宣传经费到网站上。 长期的战略目标，商业网站不仅是公共产品信息和服务的推广，它还是将买家与卖家、厂商和合作伙伴紧密结合的平台，借助这些商业网站可以消除企业与客户之间时间与空间带来的障碍。 客网站致力于为广大博客提供优质博客页面服务的商业网站。每个博客都希望借助自己的博客页面宣传自己，而博客数量越多，网站的点击率越高就越能够吸引广大的企业客户选择该商业网站作为媒介，将自己的产品展现给客户。可以说，对这些博客 网站而言：为博客提供良好的服务就意味着为网站带来更多的商业客户。因此，在具体设计实现该博客网站时，主要考虑了主流博客网站的几个主要功能。 1. 博客的注册、登录验证功能 2. 网络用户通过关键字搜索博文功能 3. 最热门博客页面推荐浏览 4. 文章详细内容及相关评论显示 5. 博客页面访问量统计 6. 博客个人文章管理维护功能 7. 博客个人文章分类管理维护功能 8. 博客个人友情链接维护功能 9. 博客个人基本信息管理维护功能 10. 博客图片上传 及 个人相册管理 11. 网络用户写留言，博 主 查看留言。 第 2节 研究的目的与意义 载了日常发生的事情和自己的兴趣爱好，把自己的 思想和知识和他人分享、交流，同时又通过 “六度空间 ”结识了更多志趣相投的朋友；而越来越多专业知识的 出现，让我们看到了 多所蕴涵的巨大的信息价值：不同的 择不同的内容，收集和整理成为很多人关注的专业 目前越来越多的人获取信息的来源是一些固定的 随着博客人数的增加， 为一种新的生活方式、新的工作方式、新的学习方式已经被越来越多的人所接受，并且在改变传统的网络和社会结构：网络信息不再是虚假不可验证的，交流和沟通更有明确的选择和方向性，单一的 思想和群体的智慧结合变的更加有效，个人出版变成人人都可以实现的梦想 在影响和改变着我们的生活 。 第 2章 设计简介及设计方案 在整个 行开发之前，要确定出整个项目的整体架构，包括系统的选型、运行环境的确定 及系统结构 设计。下面对这进行详细介绍。 第 1节 设计原则 在进行软件系统开发的最初环节，一般都需要进行系统的选型，即根据系统功能的实际需求，选择合适的开发工具及软件架构。 系统的可靠性、稳定性有比较高的要求。本系统设计时，比较主流的B/S 设计有基于 模式。相比较而言 功能相对简单，不适合做大程序；而 率相对较低，所以也不考虑。由于 式实现框架 象关系模型中的 框架及拥有事务管理 和依赖注入的 用现存框架可以更快开发系统。所以选择 术作为 开发工具。 第 2节 运行架构 为了增加系统的吞吐量，提高并发处理客户请求数量，系统采用了 务器作为主机。在数据库处理方面，不需要在数据层借助存储过程及数据库服务器端函数封装过多的业务 逻辑，因此数据库系统采用相对精巧的 误 !未找到引用源。 。 该在线博客系统服务器端如果需要布置到其他主机上，则该主机必备条件如下： 1. 服务器端操作系统：独立于操作系统的跨平台系统，客户端 000 及以上； 2. 数据库： 7 版本； 3. 务器： 以上版本，配合 计模式及 4. 客户端运行环境：能运行 以上或 以上浏览器的操作系统，配合使用 术； 5. 客户端运行工具：目前的系统采用浏览器作为客户端，为了支持 发框架，应该选择使用 以上版本浏览器。 本网站以 台， 网站实现技术，建立基于 据库系统的核心动态网页，实现博客网站前台及博客个人维护管理等功能模块。 第 3节 设计方案 为了在更短的时间内实现博客网站，我们采用 构。集成开发环境我采用对于插件即插即用的 行环境我们采用 用服务器，数据库管理系统我们采用的是 客网站主要实现注册用户可以在 服务器上开辟自己的空间，也可以发布消息，上传文件，回复消息，从服务器发送客户端的数据应用 封装 . 本系统采用的是经典的 层结构，分为表现层、中间层（业务逻辑层）和数据服务层。三层体系将业务规则、数据访问及合法性校验等工作放在中间层处理。客户端不直接与数据库交互，而是通过组件与中间层建立连接，再由中间层与数据库交互。 并利用 轻量级框架实现三层结构的设计。 即 采用的是 贫血模式，业务逻辑对象正面封装了全部的业务逻辑方法， 仅与业务逻辑组件交互即可，无须访问底层的 象。 声明式事务管理将负责业务逻辑对象方法的事务性。在贫血模式下，其分层非常清晰。 不具备领域对象的业务逻辑功能，仅仅是 架持久化所需的 仅是数据载体。贫血模型容易理解，开发便捷，但严重背离了面向对象的设计思想，所有的 不是完整的 象。 第 3章 相关 技术 介绍 第 1节 介 个词的缩写，三个词分别代表应用的三个组成部分 :模型、视图与控制器。三个部分以最少的稿合，协同工作，从而提高应用的可扩展性及可维护性。起初， 式是针对相同的数据需要不同显示的应用而设计的，其整体的效果如图 1 所示： 图 1 构 在经典的 式中，事件由控制器处理，控制器根据事件的类型改变模型或视图，反之亦然。具体地说，模型维护一个视图列表，这些视图为获得模型变化通知，通常采用观察者模式登记给模型。当模型发生改变时，模型向所有登记过的视图发送通知 :接下 来，视图从对应的模型中获得信息，然后更新自己。概括起来， 如下特点。 计模式，一个模型对应多个视图，可以减少代码的复制及代码的维护量，一旦模型发生改变，也易于维护。 1. 模型返回的数据与显示逻辑分离。模型数据可以应用任何的显示技术，例如使用 面、 板或者直接产生 档等。 2. 应用被分隔为三层，降低了各层之间的稿合，提供了应用的可扩展性。 3. 控制层的概念也很有效，由于它把不同的模型和不同的视图组合在一起，完成不同的请求。因此，控制层可 以说是包含了用户请求权限的概念。 4. 符合软件工程化管理的精神。不同的层各司其职，每一层的组件具有相同的特征，有利于通过工程化和工具化产生管理程序代码。 第 2节 起源和背景 2002 年 版了 on 2EE 一书。该书的作者是 书中， 传统的 构提出深层次的思考和质疑 。 并提出 实用主义思想。 2003 年， 域出现一个新的框架 : 该框架同样出自 手。事实上， 架是 on 2EE 一书中思想的全面体现和完善， 实用主义 想进一步改造和扩充，使其发展成更开放、清晰、全面及高效的开发框架。一经推出，就得到众多开发者的拥戴。传统 用的开发效率低，应用服务器厂商对各种技术的支持并没有真正统一，导致 应用并没有真正实现 承诺。 为开源的中间件，独立于各种应用服务器，甚至无须应用服务器的支持，也能提供应用服务器的功能，如声明式事务等。 力于 用的各层的解决方案，而不是仅仅专注于某一层的方案。可以说 企业应用开发的 一站式 选择，并贯穿表现层、业务层及持久层。然而， 不想取代那些已有的框架，而与它们无缝地整合。总结起来， 如 下 优点 : 1. 低侵入式设计，代码污染极低。 2. 独立于各种应用服务器，可以真正实现 承诺。 3. 制降低了业务对象替换的复杂性。 4. 不完全依赖于 开发者可自由选用 架的部分或全部。 第 3节 述 目前最流行的 架，其采用非常优雅的方式将 作完全包装成对象化的操作。其作者 持久层设计上极富经验，采用非常少的代码实现了整个框架，同时完全开放源代码，即使偶尔遇到无法理解的情况，也可以参照源代码来理解其在持久层上灵巧而智能的设计。目前 国内的开发人员相当 多， 文档也非常丰富，这些都为学习平了道路，因而 学习相对简单一些。下面通过对比来了解 传统 作数据库持久层之间的差异。 第 4章 需求分析 站主要是实现注册用户登录、管理相关信息、博文及相关评论、查看留言、友情链接、及图片的上传和图像的播放而为上网用户提供按博文主题搜索，查看注册用户的博文及提出相关评论，并为注册用户写留言，游览注册用户的相册、注册等功能的系统。 下面就以两种不同的用户来分析博客网站的需求。 第 1节 注册博友 首先必须在博客首页中登录填写用户名和密码，这样才能执行一些相关操作，不然就是普通用户只能查看一些信息，而不能发表博文。可以在管理页面上添加博文的分类，可以上传图片和游览自己的相册，在上传过程中可以将一张图片定义为自己的签名，在个人管理页面中注册用户还可以修改自己的个人信息。博文管理，友情链接管理及博文分类管理，用例图 2。 图 2 博客管理页面的用例图 在博客主界面中发表博文时可以选择博文类型，这样可以更好管理自己的博文。并查看和删除网友对自己的博文的一些评论、查看和删除网友留下的一些留言，提供与其他网友交流的空间。更好交流，在信息时代人们通过个人空间沟通也用来但不能在自己的博客主页面中提交评论和留言。这样在本系统中就可以为博友提供更多的个人色彩。在管理页面中添加和删除友情连接。这样博友可以在自己空间中快速定位自己的关心的网站。这样还可以让网友看到自己的一些信息。友情链接及网页访问量统计显示：在博客的个人页面中还提供了推荐给普通网络用户的相关友情链接，此外，对个人页面的访问量也在随时进行统计，并在个人页面中进行直观的显示。 博客主页面的用例图如图 3 所示： 图 3 博客主页面的用例图 第 2节 普通 用户 在博客注册页面注册成为博客的注册用户，才可以拥有自己独立的空间，进入某一博客页面查看相关文章信息时，可以随时对自己所感兴趣的文章发表评论，同时也可以查看到其他人针对该博文的评论。普通用户在阅读博文时可以在最后留下自己的一些评论。他也可以留下更多的信息。这样他可以写留言。这样他留下的信息就更快地被博友所看到。普通用户进入博友的用例图如图 4 所示： 图 4 上网博友在博客主页面的用例图 普通网友可以搜索自己关心的一些数据。并且在搜索结果中提供在结果范围内再次搜索。这样就可以将范围缩小。首页向注册用户提供登陆 模块，注册用户在博客网站首页跟上网网友一样可以查看博客和博文推荐。上网网友可以注册成为博客用户，拥有自己独立的空间。这一模块的用例图如图 5 所示： 图 5 博客首页的用例图 第 5章 系统架构设计 本系统采用严格的 E 应用结构，主要有如下几个分层。 1. 表现层 :由 面组成。 2. :使用 架 。 3. 业务逻辑层 :主要由 器管理的业务逻辑组件组成。 4. :由 7 个 件组成 ，实现类 必须 继承 供的 5. 久层 :由 7 个 成，并在 理下，完成数据库访问。 6. 数据库服务层 :使用 据库存储持久化数据。 系统的具体分层如图 5 所示。 图 6 系统结构图 在图 6 黑色大方框内的 制层、 及 件层的组件，都由器负责生成，并管理组件的实例（实例必须是单身模式的，本系统中的 本 上 是单身的）。 第 1节 系统架构说明： 本系统不仅严格按 式设计，还按 E 分层设计，将中间层严格分成业务逻辑层、 及数据持久层等。 的控制器绝对禁止持久层访问，甚至不参与业务逻辑的实现。表现层采用传统 术。 本系统采用的是典型的 层结构，分为表现层、中间层 (业务逻辑层 )和数据服务层。三层体系将业务规则、数据访问及合法性校验等工作放在中间层处理。客户端不直接与数据库交互，而是通过组件与中间层建立连接，再由中间层与数据库交互。 泛的应用和稳定的表现，为其作为表现层技术打下了坚实的基础。中间层采用的是流行的 为了将控制层与业务逻辑层分离，又细分为以 下几种。 ，就是 式里面的 C，负责逻辑层和表现层的交互。调用业务逻辑层，并将业务数据返回给表现层作组织表现，该系统的 用 架 。 (就是业务逻辑层 )，负责实现业务逻辑。业务逻辑层以 为基础，通过对 件的正面模式包装，完成系统所要求的业务逻辑。 ，负责与持久化对象交互。该层封装了数据的增、删、查、改的操作。 持久化对象。通过实体关系映射工具将关系型数据库的数据映射成对象，很方便地实现以面向对象方式操作数据库，该系统采用 为 架。 作用贯穿了整个中间层，将 、 、 及 缝整合，其数据服务层用来存放数据。 第 2节 通过使用 久层，可以避免使用传统的 作数据库，对一步包装，从而更好地使用面向对象的方式来操作数据库。保证了整个软件开发过程以面向对象的方式进行，即面向对象分析、设计及编程，透过 象持久化操作，不管插入还是查询都是通过 计 持久化对象 (面向对象分析，是指 根据系统需求提取应用中的对象，将这些对象抽象成类，再抽取出需要持久化保存的类，这些需要持久化保存的类就是持久化对象 (。该系统并没有预先设计数据库，而是完全从面向对象分析开始，设计了 7 个持久化类。本系统一共设计了如下 7 个 1. 对应博客网友的一些基本信息，必如 包括一些集合，博友的博文（ 图片（ 留言（ 这 样在系统中我们可以随时通过 访问博客的一些属性就不用编写 句来访问博友的些属性， 2. 对应博友的图片，包含 样我们可以将图片 的路径名保存到数据库中，在根据路径名访问博友上传的图片，就不用用到数据库中的 型，将图片数据格式转来转去，不过这样服务器直接存储客户的图片。 3. 对应网友留下的留言，属性有 册用户可以查看别人写的留言，但不能在自己的空间内留言。 4. 对应回 复， 包括 对于一篇博文，是网友阅读博文后对博文的评论。该评论无论是谁都可以看到。 5. 对应博文分类属性有 册用户可以在自己的空间定义一些分类，这样可以更好管理自己的博文，一个分类对应一个 个分类可能有很多分类。 6. 博客系统的核心 对应有 个博文属于一 种 分类，可以有很多回复， 7. 对应有情连接，包括 友通过添加有情连接可以在自己的空间中提供快速的自己关心的网站。 客观世界中的对象不是孤立存在的，以上 7 个 不是孤立存在的，它们之间存在复杂的关联关系。分析关联关系也是面向对象分析的必要步骤，这 7 个关系如下。 了 ，与另外 5 个都是 1关系，在 如 间存在 关系，每篇博文可以被很多人评论。 间存在 关系，即每篇博文只 能属于一种分类中，并且只属于一个博友，在 架中它提供了以 件形式出现的映射文件，完成 从 数据库表映射后，即完成面向对象的程序设计语言与关系数据库的映射。以面向对象的方式操作关系数据库。 现 在 久层之上，可使用 件再次封装数据库操作。通过 ，可以让业务逻辑层与具体持久层技术分离，一旦需要更换持久层技术时，业务逻辑层组件不需要任何改变。因此，使用 件，即意味着引入 式，使每个 件包含了数据库的访问逻辑 :每个 件可对一个数据库表完成基本的 操作。 式的实现至少需要如下三个部分。 1. 厂类。 2. 口。 3. 口的实现类。 式是一种更符合软件工程的开发方式，使用式有如下理由。 1) 式抽象出数据访问方式，业务逻辑组件无须理会底层的数据库 访问，而只专注于业务逻辑的实现。 2) 数据访问集中在独立的一层，所有的数据访问都由 象完成，这层独立的 离了数据访问的实现与其他业务逻辑，使得系统更具可维护性。 3) 有助于提升系统的可 移植性。独立的 使得系统能在不同的数据库之间轻易切换，底层的数据库实现对于业务逻辑组件是透明的。数据库移植时仅仅影响 ，不同数据库的切换不会影响业务逻辑组件，因此提高了系统的可复用性。 对于不同的持久层技术， 供一个 板，将通用的操作放在模板里完成，而对于特定的操作，则通过回调接口完成。 供的 持类是 : 件的定义 件提供了各持久化对象的基本的 作 。而在 口里则对 件包含的各种 法提供了声明，但有一些 具也可以生成基本的 法。使用 口的原因是 :避免业务逻辑组件与特定的 于 件中的方法不是开始就设计出来的，其中的很多方法可能会随着业务逻辑的需求而增加，但以下几个方法是通用 的。 根据主键加载持久化实例。 保存或更新持久化实例。 删除持久化实例。 上面涉及了 7 个 样我们必须设计 7 个对应的 个 须继承 个 对接口的一些基本的 作。7 个 下。 7 个 别封装对自己的持久化对象的一些操作。 现 件 借助于 以很方便地实现 整合提供了很好的支持， 持类是 :该 类只需要传入一个 用，即可得到一个 例，该实例功能非常强大，数据库的大部分操作也很容易实现。所有的 都继承并实现相应的 口。 而业务逻辑对象则面向接口编程，无须关心 实现细节。通过这种方式，可以让应用在不同的持久化技术之间切换。 继承 并通过 个 现类注入 在 7个 实现类就可以通过 作。并借助于 供的 两个工具类 : 以很容易地实现 件。这种简单的实现较之传统的 久化访问，简直不可同日而语。比如我现在要得到所有 ;则返回一个 部署 只需要一个 性，即可完成数据库访问。 建 数据库的 作都是有 成，并将查询结果保存在一级缓存中，每次用户提交一次会话，可能需要 成一些数据库的操作而实际的数据库访问由模板类 成，该模板类提供了大量便捷的方法，简化了数据库的访问。 件运行的基础 应用的 件以 基础，由 器负责生成并管理 件。 器负责为 件注入其运行所需要的基础 整合 供 了 大 量 工 具 类 ， 通 过，可以将 入其 器内。使用 置 前，必须为其提供对应的数据源，配置代码如下 : 在管我们采用那种数据库我就可以在修改 一些属性而不改动程序，将程序和数据库的耦合降到最低。 置 件 在将 个 可以用 一步简化了持久层讨问，其模板的操作大大降低重复操作 ;供的 持简化了 发；依赖注入简化了 控制等 ;这些都极大地提高 明式事务的管理分离了业务逻辑和事务逻辑，将应用从特定的事务逻辑中解料，使应用可以方便地在不同的事务策略之间切换。在所有的 架中， 支持最好。 供很多 性的支持，方便地处理大部分典型的 合问题，如 注入到 7个 简化操作及 持等，然后在 7个 样的话， 外， 提供了统一的异常体系及声明式事务管理等。一旦 于 管理下， 需要的基础资源，都由 供注入。 需的 执行持久化必需的 持久层访问必需的事务控制等，这些原本必须通过代码控制的逻辑，都将由 管 :，都将作为 器中的 这些 在配置文件中管理，可以提供很好的解耦。 供了 持，可以大大简化 件的开发。 器的使用，提供了 件与业务逻辑组件之间的松糯合。所有的 件，都由容器负责注入到业务逻辑组件中，其业务组件无须关心 件的实现。面向接口编程及 式的使用，提高了系统组件之间的解稿，降低了系 统重构的成本。通过 合 使持久层的访问更加容易，使用 理 1. 有效的 理 : 供了有效、简单和安全的 理。 2. 器提高了 件与业务逻辑层之间的解糯。 3. 式的使用，降低了系统重构的代价。 4. 方便的事务管理 : 事务管理处理会限制 表现，而 5. 6. 通用的资源管理 : 管理 使得 配置值很容易被管理和修改，无须使用 配置文件。 7. 异常包装 :够包装 常，把它们从 为 开发者可选择在恰当的层处理数据中不可恢复的异常，从而避免烦琐的 异常声明。配置 件所有继承 现类，必须为其提供 引用。由于所有 件都需要注入 用，因此可以使用 承简化 件的配置。本应用同样将所有的 件配置在单独的配置文件中 例如：由于 7 个 必须利用 器注入 们先配一个 后 7 个 继承该模板这样就可以简化 件 以 例， 以 父 属性 其余 6 个 配置 相似 。 从上面的配置文件可以看出 器在动时就可以向 入 3节 实现 件采用正面模式封装多个 件， 象与 件之间的关 件需要实现的业务方法主要取决于业务的需要，通常需要在业务组件中包含对应的方法。 业务层组件的实现业务层组件与具体的数据库访问技术分离，使所有的数据库访问依赖于 件， 定义一个 包装 7 个 样就可以把逻辑层和 开，达到松散耦合的效果。事务管理将推迟到 件而不是 件，因为只有对业务逻辑方法添加事务才有实际的意义，对于单个 法 (基本的 法 )增 加事务操作是没有太大实际意义的。关于事务属性的配置，本系统 使用 供的 置事务代理。 这样 不必为每个目标对象配置代理 避免了目标对象被直接调用。部暑业务层组件单独配置系统的业务逻辑层，可避免因配置文件过大引起配