基于web的学生公寓管理系统的设计与实现毕业设计（论文） .doc

大连交通大学信息工程学院大连交通大学信息工程学院 毕业设计毕业设计 论文论文 任务书任务书 题 目 基于 web 的学生公寓管理系统的设计与实现 任务及要求 任务及要求 1 设计 研究 内容和要求 任务 1 基于 web 的学生公寓管理系统 完成实习报告 字数不少于 3000 第三周交给 指导老师 2 结合自己实习情况安排进度 填写进度计划表 第二周完成后交给指导老师签 字 并严格执行 3 按照软件工程思想 独立完成系统的设计和程序开发 完成代码估计 2000 行 左右 4 用 web 技术实现 web 的学生公寓管理系统基本功能 5 程序简洁 算法可行 运行情况良好 要求 1 每周和指导老师至少见面沟通一次 回报课题进展情况 接受老师询问 2 接到任务书后 查阅与题目及专业相关的外文资料进行翻译 要求不少于 10000 个外文字符 译出汉字不得少于 3000 于第四周交给指导老师审阅 3 毕业设计第 13 周完成毕业论文的装订 并由指导老师评阅 论文要求 12000 字以上 包括综述 系统总体设计 系统实现 性能分析 结论等 4 教学第 13 周通过中软及教研室组织进行软件验收 验收时要提供软件使用说 明书 5 于第 13 周提出毕业答辩申请并签字 6 第 14 周答辩 要求制作 ppt 2 原始依据 通过大学几年的学习 已经学习了诸如软件工程 数据库原理及应用 数据结 构 c visual basic java 等多门程序设计语言和网络等基础知识和专业知识 学生有能力而且可以独立完成小中型项目的设计与开发 学校现有设备和环境可以提 供给学生实习和上机 而且具有专业老师可以指导学生 3 参考文献 1 耿祥义 张跃平 java 2实用教程 第三版 m 北京 清华大学出版社 2006 8 2 黄晓东 java课程设计案例精编 m 中国水利水电出版社 2007 3 崔晓静 严小舟 java语言程序设计 m 中国铁道出版社 2007 12 4 王森 快易通java程序设计 m 北京 北京大学出版社 2000 5 袁玉宇 软件测试与质量保证 m 北京 邮电大学出版社 2008 6 朱辉生 大型数据库系统概论 m 北京 高等教育出版社 2006 7 叶核亚 陈立著 java2 程序设计实用教程 北京电子工业出版社 2003 5 8 周颢 网络编程语言 jsp 实例教程 m 电子工业出版社 2002 6 9 mark matthews jim cole joseph d gradecki mysql and java developer s guide m john wiley instead we ll focus on the basic fetching strategies and how to tune hibernate mapping files for best default fetching for all methods before we look at the fetching strategies we ll give an overview of the retrieval methods we mention the hibernate caching system but fully explore it in the next chapter let s start with the simplest case retrieval of an object by giving its identifier value navigating the object graph should self explanatory you saw a simple retrieval by identifier earlier in this chapter but there is more to know about it retrieving objects by identifier the following hibernate code snippet retrieves a user object from the database user user user session get user class userid the get method is special because the identifier uniquely identifies a single instance of a class hence it s common for applications to use the identifier as aconvenient handle to a persistent object retrieval by identifier can use the cachewhen retrieving an object avoiding a database hit if the object is already cached hibernate also provides a load method user user user session load user class userid the load method is older get was added to hibernate s api due to userrequest the difference is trivial if load can t find the object in the cache or database an exception isthrown the load method never returns null the get method returnsnull if the object can t be found the load method may return a proxy instead of a real persistent instance a proxy is a placeholder that triggers the loading of the real object when it s accessed for the first time we discuss proxies later in this section on the other hand get never returns a proxy choosing between get and load is easy if you re certain the persistentobject exists and nonexistence would be considered exceptional load is a good option if you aren t certain there is a persistent instance with the given identifier use get and test the return value to see if it s null using load has a further implication the application may retrieve a valid reference a proxy to a persistent instance without hitting the database to retrieve its persistent state so load might not throw an exception when it doesn t find the persistent object in the cache or database the exception would be thrown later when the proxy is accessed of course retrieving an object by identifier isn t as flexible as using arbitrary queries introducing hql the hibernate query language is an object oriented dialect of the familiar relational query language sql hql bears close resemblances to odmg oql andejb ql but unlike oql it s adapted for use with sql databases and it s much more powerful and elegant than ejb ql however ejb ql 3 0 will be very similar to hql hql is easy to learn with basic knowledge of sql hql isn t a data manipulation language like sql it s used only for object retrieval not for updating inserting or deleting data object state synchronization is the job of the persistence manager not the developer most of the time you ll only need to retrieve objects of a particular class and restrict by the properties of that class for example the following query retrieves a user by first name query q session createquery from user u where u firstname fname q setstring fname max list result q list after preparing query q we bind the identifier value to a named parameter fname the result is returned as a list of user objects hql is powerful and even though you may not use the advanced features all the time you ll need them for some difficult problems for example hql supports the following the ability to apply restrictions to properties of associated objects related by reference or held in collections to navigate the object graph using query language the ability to retrieve only properties of an entity or entities without the overhead of loading the entity itself in a transactional scope this is sometimes called a report query it s more correctly called projection the ability to order the results of the query the ability to paginate the results aggregation with group by having and aggregate functions like sum min and max outer joins when retrieving multiple objects per row the ability to call user defined sql functions subqueries nested queries we discuss all these features in chapter 7 together with the optional native sql query mechanism query by criteria the hibernate query by criteria qbc api lets you build a query by manipulating criteria objects at runtime this approach lets you specify constraints dynamically without direct string manipulations but it doesn t lose much of the flexibility or power of hql on the other hand queries expressed as criteria are often less readable than queries expressed in hql retrieving a user by first name is easy using a criteria object criteria criteria session createcriteria user class criteria add expression like firstname max list result criteria list a criteria is a tree of criterion instances the expression class provides static factory methods that return criterion instances once the desired criteria tree is built it s executed against the database many developers prefer qbc considering it a more object oriented approach they also like the fact that the query syntax may be parsed and validated at compile time whereas hql expressions aren t parsed until runtime the nice thing about the hibernate criteria api is the criterion framework this framework allows extension by the user which is difficult in the case of a query language like hql query by example as part of the qbc facility hibernate supports query by example qbe the idea behind qbe is that the application supplies an instance of the queried class with certain property values set to nondefault values the query returns all persistent instances with matching property values qbe isn t a particularly powerful approach but it can be convenient for some applications the following code snippet demonstrates a hibernate qbe user exampleuser new user exampleuser setfirstname max criteria criteria session createcriteria user class criteria add example create exampleuser list result criteria list a typical use case for qbe is a search screen that allows users to specify a range of property values to be matched by the returned result set this kind of functionality can be difficult to express cleanly in a query language string manipulations would be required to specify a dynamic set of constraints both the qbc api and the example query mechanism are discussed in more detail in chapter 7 you now know the basic retrieval options in hibernate we focus on the strategies for fetching object graphs in the rest of this section a fetching strategy defines what part of the object graph or what subgraph is retrieved with a query or load operation fetching strategies in traditional relational data access you d fetch all the data required for a particular with a single sql query taking advantage of inner and outer joins to retrieve related entities some primitive orm implementations fetch data piecemeal with many requests for small chunks of data in response to the application s navigating a graph of persistent objects this approach doesn t make efficient use of the relational database s join capabilities in fact this data access strategy scales poorly by nature one of the most difficult problems in orm probably the most difficult is providing for efficient access to relational data given an application that prefers to treat the data as a graph of objects for the kinds of applications we ve often worked with multi user distributed web and enterprise applications object retrieval using many round trips to from the database is unacceptable hence we argue that tools should emphasize the r in orm to a much greater extent than has been traditional the problem of fetching object graphs efficiently with minimal access to the database has often been addressed by providing association level fetching strategies specified in metadata of the association mapping the trouble with this approach is that each piece of code that uses an entity requires a different set of associated objects but this isn t enough we argue that what is needed is support for fine grained runtime association fetching strategies hibernate supports both it lets you specify a default fetching strategy in the mapping file and then override it at runtime in code hibernate allows you to choose among four fetching strategies for any association in association metadata and at runtime immediate fetching the associated object is fetched immediately using a sequential database read or cache lookup lazy fetching the associated object or collection is fetched lazily when it s first accessed this results in a new request to the database unless the associated object is cached eager fetching the associated object or collection is fetched together with the owning object using an sql outer join and no further database request is required batch fetching this approach may be used to improve the performance of lazy fetching by retrieving a batch of objects or collections when a lazy association is accessed batch fetching may also be used to improve the performance of immediate fetching let s look more closely at each fetching strategy immediate fetching immediate association fetching occurs when you retrieve an entity from the database and then retrieve another associated entity or entities in a further request to the database or cache immediate fetching isn t usually an efficient fetching strategy unless you expect the associated entities to almost always be cached already lazy fetching when a client requests an entity and its associated graph of objects from the database it isn t usually necessary to retrieve the whole graph of every indirectly associated object you wouldn t want to load the whole database into memory at once for example loading a single category shouldn t trigger the loading of all items in that category lazy fetching lets you decide how much of the object graph is loaded in the first database hit and which associations should be loaded only when they re first accessed lazy fetching is a foundational concept in object persistence and the first step to attaining acceptable performance we recommend that to start with all associations be configured for lazy or perhaps batched lazy fetching in the mapping file this strategy may then be overridden at runtime by queries that force eager fetching to occur eager outer join fetching lazy association fetching can help reduce database load and is often a good default strategy however it s a bit like a blind guess as far as performance optimization goes eager fetching lets you explicitly specify which associated objects should be loaded together with the referencing object hibernate can then return the associated objects in a single database request utilizing an sql outer join performance optimization in hibernate often involves judicious use of eager fetching for particular transactions hence even though default eager fetching may be declared in the mapping file it s more common to specify the use of this strategy at runtime for a particular hql or criteria query batch fetching batch fetching isn t strictly an association fetching strategy it s a technique that may help improve the performance of lazy or immediate fetching usually when you load an object or collection your sql where clause specifies the identifier of the object or object that owns the collection if batch fetching is enabled hibernate looks to see what other proxied instances or uninitialized collections are referenced in the current session and tries to load them at the same time by specifying multiple identifier values in the where clause we aren t great fans of this approach eager fetching is almost always faster batch fetching is useful for inexperienced users who wish to achieve acceptable performance in hibernate without having to think too hard about the sql that will be executed note that batch fetching may be familiar to you since it s used by many ejb2 engines we ll now declare the fetching strategy for some associations in our mapping metadata hibernate 的实践与应用 检索对象 从数据库中检索对象是使用hibernate最有趣 也是最复杂 的部分 hibernate 提供 下列方式 从数据库中提取对象 导航对象图 从一个已经装载的对象开始 通过像auser getaddress getcity 的属 性访问器方法访问相关的对象 如果session是打开的 当你导航图时 hibernate会自动装 载图的节点 当对象的唯一标识符值是已知的时候 通过标识符检索是最方便最有性能的方法 使用hibernate查询语言 hql 它是完全面向对象的查询语言 使用hibernate 条件api 它提供了类型安全的面向对象的方式执行查询而不需要操纵 字符串 这种便利性包括基于例子对象的查询 使用本地sql查询 这种查询hibernate只关心把jdbc 结果集映射到持久对象图 在 hibernate 应用程序中 将结合使用这几种技术 每一种检索方法可能使用不同的抓取策略 那就是定义持久对象图的哪个部分应该检索的策略 目标是在你的应用程序中为每个使用 场合发现最好的检索方法和抓取策略 同时最小化查询语句的数量以获得最好的性能 在这 一节我们不仔细讨论每个检索方法 相反 我们将集中于基本的抓取策略和怎样调整 hibernate 映射文件以便对所有的方法达到最好的默认抓取性能 在看抓取策略之前 我们 将给出检索方法的概述 我们提到hibernate缓存系统但是将在下一章完全研究它 让 我们开始最简单的例子 通过给定的标识符值检索对象 导航对象图不加以说明了 在这一章的前半部分你已经看过一个简单的通过标识符检索的例子 但是还有许多需要 知道 根据标识符检索对象 下面的hibernate 代码片断从数据库中检索user对象 user user user session get user class userid get 方法很特别 因为标识符唯一地标识类的单个实例 因此 应用程序通常使用标 识符方便地处理持久对象 当用标识符检索对象时可以使用缓存 如果对象已经缓存了可以 避免数据库碰撞 hit hibernate也提供了load 方法 user user user session load user class userid load 方法是旧的 因为用户的请求已经把get 方法加入到hibernate api 不同之处 微不足道 如果 load 方法不能在缓存或数据库中找到对象会抛出异常 load 方法从不返 回 null 如果对象没找到 get 方法返回 null load 方法返回代理而不是真正的持久实例 代理是一个占位符 当第一次调用它时才 装载真正的对象 我们将在本节的后半部分讨论代理 另一方面 get 方法从不返回代理 在get 和load 之间选择很简单 如果你能确定持久实例存在 不存在将会认为是异常 那么load 是很好的选择 如果你不能确定给定的标识符是否有一个实例 使用get 测试 返回值 看它是否为null 使用load 有更深的含义 应用程序可能检索一个对持久实例的 引用 代理 而不会强制数据库检索它的持久状态 因此 在缓存或数据库中不能找到持久 对象时load 不能抛出异常 异常会在以后抛出 当代理被访问的时候 当然 使用标识符检索对象没有使用任意的查询复杂 介绍hql hibernate 查询语言是与其相似的关系型查询语言sql 的面向对象方言 hql与odmgoql 和ejb ql很相像 但是不像oql 它是用于sql数据库的 并且比ejb ql更强大更优秀 然而 ejb ql3 0 将会与hql非常相似 只要有sql基础hql非常容易学 hql不是像sql这样的数 据操纵语言 它只能用来检索对象 不能更新 插入或删除数据 对象状态同步是持久管理 器的工作 而不是开发者的工作 大部分时间你仅仅需要检索特定类的对象 并且受那个类的属性的约束 例如 下面的 查询根据姓来检索用户 query q session createquery from user u where u firstname fname q setstring fname max list result q list 准备查询q 之后 我们把标识符值绑定到命名参数fname 上 user 对象的list 作为结 果返回 hql 功能非常强大 虽然你不会一直使用其高级特征 但是你将会需要它们来解决 一些复杂问题 例如 hql支持下面这些功能 通过引用或持有集合 使用查询语言导航对象图 把限制条件应用到相关的关联对象的 属性上的能力 在事务范围仅仅检索一个或多个实体的属性而不是装载整个实体的能力 有时把它称为 report query 更正确的说法是projection 排列查询结果的能力 分页查询的能力 使用group having及统计函数 如sum min和max 进行统计 当在一行中检索多个对象时使用外联接 调用用户自定义的sql函数的能力 子查询 嵌套查询 我们将在第七章把所有这些特性同可选的本地 sql 查询机制放到一起讨论 通过条件查询 hibernate的通过条件查询 query by criteria qbc api 允许你在运行时通过操纵 查询对象来建立查询 这种方法允许动态的指定约束而不是直接操纵字符串 但是 它也丢 掉了许多hql的复杂性或强大功能 另一方面 以条件表示的查询比以hql表示的查询可读性 差 通过名字检索用户使用查询对象更简单 criteria criteria session createcriteria user class criteria add expression like firstname max list result criteria list criteria 是一个criterion 实例树 expression 类提供返回criterion 实例的静态工 厂方法 一旦建立了想要的查询树 就会对数据库执行 许多开发者喜欢qbc 把它认为是更复 杂的面向对象方法 他们也喜欢查询语法在编译时解释和验证的事实 而hql只有在运行时 才解释 关于hibernate criteria api最好的方面是criterion框架 这个框架允许用户对其进 行扩展 像 hql 这样的查询语言却很困难 通过例子查询 作为qbc 便利性的一部分 hibernate支持通过例子查询 qbe 使用qbe 的前提条件 是应用程序支持具有某种属性值集合 非默认值 的查询类实例 查询返回所有的匹配属性 值的持久实例 qbe 不是特别强大的方法 但是对一些应用程序却很方便 下面的代码片断 演示hibernate的qbe user exampleuser new user exampleuser setfirstname max qbe 的典型用例是允许用户指定属性值范围的查找屏幕 指定属性值范围用来匹配返回 的结果集 这种功能在查询语言中很难清晰地表达 操纵字符串需要指定动态的约束集 qbc api和这种查询机制的例子将在第七章详细讨论 现在你知道hibernate中基本的检索选 项 我们在本节的剩余部分关注对象图的抓取策略 抓取策略定义了用查询或装载操作检索 对象图 或子图 的哪一部分 抓取策略 传统的关系数据访问利用内连接和外连接检索相关的实体 用单个sql查询抓取对某个 计算所需要的所有数据 一些原始的orm实现分开抓取数据 多次请求小块的数据 应用程 序作为响应也会多次导航持久对象图 这种方法不能有效利用关系数据库的连接能力 实际 上 这种数据访问策略将来很难扩展 orm中的一个最困难的问题 可能是最困难的 是提 供对关系数据库的有效访问 鉴于应用程序喜欢把数据当成对象图看待 对于我们经常开发的多种应用程序 多用户 分布式 web 和企业应用 检索对象时 多次往返于数据库是不可取的 因此 我们讨论的工具比传统的工具更强调orm中的r 关系 有效地抓取对象图的问题已经通过在关联映射的元数据中指定关联级抓取策略解决了 这种方法存在的问题是每段代码使用一个需要不同集合的相关对象的实体 但是这是不 够的我们需要的是支持细粒度的运行时关联抓取策略 hibernate 两者都支持 允许在映射 文件中指定默认的抓取策略 然后在代码运行时重载 hibernate对于任何关联允许在四种抓取策略中选择 在关联元数据和运行时 立即抓取 立即抓取关联的对象 使用连续的数据库读 或缓存查找 延迟抓取 当第一次访问时 延迟 抓取相关的对象或集合 这个结果在对数据库的 新请求中 除非缓存了相关的对象 提前抓取 相关的对象或集合同拥有它们的对象一起抓取 使用sql外连接 不需要额 外的数据库请求 批量抓取 在访问延迟关联时 这种方法通过检索一批对象或集合来提高延迟抓取的性 能 批量抓取也用来提高立即抓取的性能 让我们仔细看看每种抓取策略 立即抓取 立即的关联抓取发生在从数据库中检索实体然后立即在下一个对数据库或缓存的请求中 检索另一个 或一些 相关的实体的时候 立即抓取通常不是有效的抓取策略除非希望关联 的实体一直被缓存 延迟抓取 当客户请求数据库中的实体及其相关的对象图时 通常不必检索每个 非直接的 关联 对象的整个对象图 你不希望立即把整个数据库装载到内存中 例如 装载单个category 不应该触发装载这个目录的所有item 延迟抓取能够让你决定第一次访问数据库时装载多少 对象图 并且与其关联的对象只有在第一次访问时才装载 延迟抓取是对象持久化中的基本 内容 而且是取得可接受性能的第一步 我们推荐在开始的时候把映射文档中所有的关联映射为延迟 或可能是批量延迟 抓取 这种策略然后被强制提前抓取发生的查询重载 提前 外连接 抓取 延迟关联抓取能够帮助减少数据库装载 而且通常是一种好的默认策略 然而 这在性 能优化发生前有点盲目猜测 提前抓取让你显式地指定哪些关联的对象应该同引用它们的对象一起装载 hibernate 然后在单个数据库请求中使用sql的outer join 返回关联的对象 hibernate的性能优化通 常包括针对某些事务明智地使用提前抓取 因此 即使在映射文件中声明了默认的抓取策略 在运行时对于某个hql或条件查询指定使用这种策略更普遍 批量抓取 批量抓取不是严格的关联抓取策略 它是帮助提高延迟 或立即 抓取性能的一种技术 通常 当装载对象或集合的时候 sql的where 子句指定对象的标识符或拥有集合的对象 如果开启了批量抓取 hibernate看起来知道什么会在当前session 中引用其它代理实 例或未初 始化的集合 尽量通过在where 子句中指定多个标识符值来同时装载这些对象 我们不 是这种方法的热心者 提前抓取几乎一直是更快的 批量抓取对那些希望用hibernate 达到 可接受的性能而不用想太多关于要执行的sql 的经验不足的用户很有用 注意 你可能很 熟悉批量抓取 因为它已经被许多ejb2 引擎使用 现在我们在映射元数据中对一些关联声明抓取策略 大连交通大学信息工程学院大连交通大学信息工程学院 毕业设计毕业设计 论文论文 调研报告调研报告 学生姓名学生姓名 方广志方广志 专业班级专业班级 软件工程软件工程 08 308 3 班班 指导教师指导教师 阎树昕阎树昕 王立娟王立娟 职职 称称 高工高工 讲师讲师 所在单位所在单位 信息科学系信息科学系软件工程软件工程教研室教研室 教研室主任教研室主任 刘瑞杰刘瑞杰