基于web的学生公寓管理系统的设计与实现毕业设计(论文)

《基于web的学生公寓管理系统的设计与实现毕业设计(论文)》由会员分享，可在线阅读，更多相关《基于web的学生公寓管理系统的设计与实现毕业设计(论文)（73页珍藏版）》请在装配图网上搜索。

1、大连交通大学信息工程学院毕业设计(论文)任务书题 目 基于web的学生公寓管理系统的设计与实现任务及要求：1.设计（研究）内容和要求任务：1、 基于web的学生公寓管理系统，完成实习报告，字数不少于3000，第三周交给指导老师。2、 结合自己实习情况安排进度，填写进度计划表，第二周完成后交给指导老师签字，并严格执行。3、 按照软件工程思想，独立完成系统的设计和程序开发，完成代码估计2000行左右。4、 用Web技术实现web的学生公寓管理系统基本功能。5、 程序简洁，算法可行，运行情况良好。要求：1、 每周和指导老师至少见面沟通一次，回报课题进展情况，接受老师询问。2、 接到任务书后，查阅与题

2、目及专业相关的外文资料进行翻译，要求不少于10000个外文字符，译出汉字不得少于3000，于第四周交给指导老师审阅。3、 毕业设计第13周完成毕业论文的装订，并由指导老师评阅。论文要求12000字以上，包括综述、系统总体设计、系统实现、性能分析、结论等。4、 教学第13周通过中软及教研室组织进行软件验收，验收时要提供软件使用说明书。5、 于第13周提出毕业答辩申请并签字。6、 第14 周答辩，要求制作PPT2.原始依据通过大学几年的学习，已经学习了诸如软件工程、数据库原理及应用、数据结构、C+、Visual Basic、JAVA等多门程序设计语言和网络等基础知识和专业知识，学生有能力而且可以独

3、立完成小中型项目的设计与开发。学校现有设备和环境可以提供给学生实习和上机，而且具有专业老师可以指导学生。3.参考文献1 耿祥义.张跃平.Java 2实用教程（第三版）M.北京:清华大学出版社.2006.82 黄晓东.java课程设计案例精编M.中国水利水电出版社.20073 崔晓静.严小舟.java语言程序设计M.中国铁道出版社.2007.124 王森.快易通Java程序设计M.北京:北京大学出版社.20005 袁玉宇.软件测试与质量保证M.北京：邮电大学出版社.20086 朱辉生.大型数据库系统概论M.北京：高等教育出版社.20067 叶核亚.陈立著.Java2程序设计实用教程.北京电子工业

4、出版社.2003.58 周颢.网络编程语言JSP实例教程M.电子工业出版社.2002.69 Mark Matthews. Jim Cole. Joseph D. Gradecki. MySQL and Java Developers GuideM. John Wiley & Sons Inc.200310 史济民.软件工程原理.方法与应用M.高等教育出版社.200211 Charles Bell. Mats Kindahl. Lars Thalmann. MySQL High Availability: Tools for Robust Data Centers. OReilly Media.

5、2010指导教师签字：教研室主任签字： 年 月 日大连交通大学信息工程学院毕业设计(论文)进度计划与考核表学生姓名方广志专业班级软件工程08-3班指导教师阎树昕王丽娟本课题其他人员无题目基于web的学生公寓管理系统的设计与实现日期计划完成内容完成情况指导老师检查签字第1周拟订毕业论文进度计划与考核表第2周完成实习或调研报告第3周提交外文文献翻译资料第4周系统概要设计阶段第5周系统详细设计阶段第6周系统编码实施、完成论文初稿第7周完成系统编码实施第8周系统编码调试、提交论文初稿第9周完成系统编码调试、完善毕业论文第10周完成撰写毕业设计论文编写及代码测试第11周完成论文终稿、准备毕业论文打印、装

6、订第12周提交毕业论文终稿及代码第13周完成毕业论文 第14周毕业论文答辩指导教师签字： 年月日注：“计划完成内容”由学生本人认真填写，其它由指导教师考核时填写。大连交通大学信息工程学院毕业设计(论文)外文翻译学生姓名 方广志 专业班级 软件工程08-3班 指导教师 阎树昕王立娟 职 称 高工讲师 所在单位 信息科学系软件工程教研室 教研室主任 刘瑞杰 完成日期 2012 年 4 月 13 日Hibernate In ActionRetrieving objectsRetrieving persistent objects from the database is one of the mos

7、t interesting (andcomplex) parts of working with Hibernate. Hibernate provides the following waysto get objects out of the database: Navigating the object graph, starting from an already loaded object, byaccessing the associated objects through property accessor methods such as a User.getAddress().g

8、etCity(). Hibernate will automatically load (or preload)nodes of the graph while you navigate the graph if the Session is open. Retrieving by identifier, which is the most convenient and performant method when the uniqueidentifier value of an object is known. Using the Hibernate Query Language (HQL)

9、, which is a full object-orientedquerylanguage. Using the, Hibernate Criteria API, which provides a type-safe and objectoriented way to perform queries without the need for string manipulation.This facility includes queries based on an example object. Using native SQL queries, where Hibernate takes

10、care of mapping the JDBC result sets to graphs of persistent objects.In your Hibernate applications, youll use a combination of these techniques.Each retrieval method may use a different fetching strategythat is, a strategy that defines what part of the persistent object graph should be retrieved. T

11、he goal is to find the best retrieval method and fetching strategy for every use case in your application while at the same time minimizing the number of SQL queries for best performance.We wont discuss each retrieval method in much detail in this section; instead well focus on the basicfetching str

12、ategies and how to tune Hibernate mapping files for best default fetching for all methods. Before we look at the fetching strategies, well give an overview of the retrieval methods. (We mention the Hibernate caching system but fully explore it in the next chapter.) Lets start with the simplest case,

13、 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 identifierThe following Hibernate code snippet retrieves a User obj

14、ect 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 its common for applications to use the identifier as aconvenient handle to a persistent object. Retrieval by identifier

15、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 Hibernates API due to userrequest. The difference is trivial:

16、 If load() cant find the object in the cache or database, an exception isthrown. The load() method never returns null. The get() method returnsnull if the object cant be found. The load() method may return a proxy instead of a real persistent instance.A proxy is a placeholder that triggers the loadi

17、ng of the real object when its 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 youre certain the persistentobject exists, and nonexistence would be considered exceptional, load() is a

18、good option. If you arent certain there is a persistent instance with the given identifier, use get() and test the return value to see if its null. Using load() has a further implication: The application may retrieve a valid reference (a proxy) to a persistent instance without hitting the database t

19、o retrieve its persistent state. So load() might not throw an exception when it doesnt 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 isnt as flexible as using arbitrary queries.Introd

20、ucing HQLThe 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, its adapted for use with SQL databases, and its much more powerful and elegant than EJB-QL (However, EJB-QL 3.0 will

21、be very similar to HQL.) HQL is easy to learn with basic knowledge of SQL. HQL isnt a data-manipulation language like SQL. Its 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

22、the time, youll 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();Afte

23、r 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, youll need them for some difficult problems. For example, HQL supports the following: Th

24、e 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

25、scope. This is sometimes called a report query; its 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

26、 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 criteriaThe Hibernate query by criteria (QBC) API lets you build a query by manipulating criteria objects at ru

27、ntime. This approach lets you specify constraints dynamically without direct string manipulations, but it doesnt 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 eas

28、y 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 d

29、esired criteria tree is built, its 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 arent parsed until runtime.The nice thing ab

30、out the Hibernate Criteria API is the Criterion framework.This framework allows extension by the user, which is difficult in the case of a querylanguage like HQL.Query by exampleAs part of the QBC facility, Hibernate supports query by example (QBE). The idea behind QBE is that the application suppli

31、es 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 isnt a particularly powerfulapproach, but it can be convenient for some applications. The following code snippet demonstrates a H

32、ibernate 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 val

33、ues 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.

34、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 strategiesIn traditional relati

35、onal data access, youd 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 applications na

36、vigating a graph of persistent objects. This approach doesnt make efficient use of the relational databases join capabilities. In fact, this data access strategy scales poorly by nature. One of the most difficult problems in ORMprobably the most difficultis providing for efficient access to relation

37、al data, given an application that prefers to treat the data as a graph of objects.For the kinds of applications weve 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

38、 should emphasize the R inORM 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 t

39、rouble with this approach is that each piece of code that uses an entity requires a different set of associated objects. But this isnt 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 fetc

40、hing 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 fetchingThe associated object is fetched immediately, using a sequential database read (or ca

41、che lookup). Lazy fetchingThe associated object or collection is fetched “lazily,” when its first accessed. This results in a new request to the database (unless the associated object is cached). Eager fetchingThe associated object or collection is fetched together with the owning object, using an S

42、QL outer join, and no further database request is required. Batch fetchingThis 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 immediat

43、e fetching.)Lets look more closely at each fetching strategy.Immediate fetchingImmediate 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 isnt usually an

44、 efficient fetching strategy unless you expect the associated entities to almost always be cached already.Lazy fetchingWhen a client requests an entity and its associated graph of objects from the database, it isnt usually necessary to retrieve the whole graph of every (indirectly) associated object

45、. You wouldnt want to load the whole database into memory at once; for example, loading a single Category shouldnt 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

46、only when theyre 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 th

47、en be overridden at runtime by queries that force eager fetching to occur.Eager (outer join) fetchingLazy association fetching can help reduce database load and is often a good default strategy. However, its a bit like a blind guess as far as performance optimization goes.Eager fetching lets you exp

48、licitly 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 particu

49、lar transactions. Hence, even though default eager fetching may be declared in the mapping file, its more common to specify the use of this strategy at runtime for a particular HQL or criteria query.Batch fetchingBatch fetching isnt strictly an association fetching strategy; its a technique that may

50、 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 uniniti

51、alized collections are referencedin the current session and tries to load them at the same time by specifying multiple identifier values in the WHERE clause.We arent great fans of this approach; eager fetching is almost always faster. Batch fetching is useful for inexperienced users who wish to achi

52、eve 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 its used bymany EJB2 engines.)Well now declare the fetching strategy for some associations in our mapping metadata.Hibernate的实践与应用检索对象

53、从数据库中检索对象是使用Hibernate最有趣（也是最复杂）的部分。Hibernate 提供下列方式从数据库中提取对象：导航对象图，从一个已经装载的对象开始，通过像aUser.getAddress().getCity()的属性访问器方法访问相关的对象。如果Session是打开的，当你导航图时，Hibernate会自动装载图的节点。当对象的唯一标识符值是已知的时候，通过标识符检索是最方便最有性能的方法。使用Hibernate查询语言（HQL），它是完全面向对象的查询语言。使用Hibernate 条件API，它提供了类型安全的面向对象的方式执行查询而不需要操纵字符串。这种便利性包括基于例子对象的

54、查询。使用本地SQL查询，这种查询Hibernate只关心把JDBC 结果集映射到持久对象图。在Hibernate 应用程序中，将结合使用这几种技术。每一种检索方法可能使用不同的抓取策略那就是定义持久对象图的哪个部分应该检索的策略。目标是在你的应用程序中为每个使用场合发现最好的检索方法和抓取策略，同时最小化查询语句的数量以获得最好的性能。在这一节我们不仔细讨论每个检索方法，相反，我们将集中于基本的抓取策略和怎样调整Hibernate 映射文件以便对所有的方法达到最好的默认抓取性能。在看抓取策略之前，我们将给出检索方法的概述。（我们提到Hibernate缓存系统但是将在下一章完全研究它。）让我们

55、开始最简单的例子，通过给定的标识符值检索对象（导航对象图不加以说明了）。在这一章的前半部分你已经看过一个简单的通过标识符检索的例子，但是还有许多需要知道。根据标识符检索对象下面的Hibernate 代码片断从数据库中检索User对象：User user = (User) session.get(User.class, userID);get()方法很特别，因为标识符唯一地标识类的单个实例。因此，应用程序通常使用标识符方便地处理持久对象。当用标识符检索对象时可以使用缓存，如果对象已经缓存了可以避免数据库碰撞（hit）。Hibernate也提供了load()方法：User user = (User

56、) session.load(User.class, userID);load()方法是旧的，因为用户的请求已经把get()方法加入到Hibernate API。不同之处微不足道：l 如果load()方法不能在缓存或数据库中找到对象会抛出异常。load()方法从不返回null。如果对象没找到get()方法返回null。load()方法返回代理而不是真正的持久实例。代理是一个占位符，当第一次调用它时才装载真正的对象。我们将在本节的后半部分讨论代理。另一方面，get()方法从不返回代理。在get()和load()之间选择很简单：如果你能确定持久实例存在，不存在将会认为是异常，那么load()是很好

57、的选择。如果你不能确定给定的标识符是否有一个实例，使用get()测试返回值，看它是否为null。使用load()有更深的含义：应用程序可能检索一个对持久实例的引用（代理）而不会强制数据库检索它的持久状态。因此，在缓存或数据库中不能找到持久对象时load()不能抛出异常。异常会在以后抛出，当代理被访问的时候。当然，使用标识符检索对象没有使用任意的查询复杂。介绍HQLHibernate 查询语言是与其相似的关系型查询语言SQL 的面向对象方言。HQL与ODMGOQL和EJB-QL很相像，但是不像OQL，它是用于SQL数据库的，并且比EJB-QL更强大更优秀（然而，EJB-QL3.0 将会与HQL非

58、常相似。）只要有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

59、作为结果返回。HQL 功能非常强大，虽然你不会一直使用其高级特征，但是你将会需要它们来解决一些复杂问题。例如，HQL支持下面这些功能：通过引用或持有集合（使用查询语言导航对象图）把限制条件应用到相关的关联对象的属性上的能力。在事务范围仅仅检索一个或多个实体的属性而不是装载整个实体的能力。有时把它称为report query，更正确的说法是projection。排列查询结果的能力。分页查询的能力。使用group、having及统计函数（如sum、min和max）进行统计。当在一行中检索多个对象时使用外联接。调用用户自定义的SQL函数的能力。子查询（嵌套查询）。我们将在第七章把所有这些特性同可选的

60、本地SQL查询机制放到一起讨论。通过条件查询Hibernate的通过条件查询（query by criteria(QBC)）API 允许你在运行时通过操纵查询对象来建立查询。这种方法允许动态的指定约束而不是直接操纵字符串，但是，它也丢掉了许多HQL的复杂性或强大功能。另一方面，以条件表示的查询比以HQL表示的查询可读性差。通过名字检索用户使用查询对象更简单：Criteria criteria = session.createCriteria(User.class);criteria.add( Expression.like(firstname, Max) );List result = cri

61、teria.list();Criteria 是一个Criterion 实例树。Expression 类提供返回Criterion 实例的静态工厂方法。一旦建立了想要的查询树，就会对数据库执行。许多开发者喜欢QBC，把它认为是更复杂的面向对象方法。他们也喜欢查询语法在编译时解释和验证的事实，而HQL只有在运行时才解释。关于Hibernate Criteria API最好的方面是Criterion框架。这个框架允许用户对其进行扩展，像HQL这样的查询语言却很困难。通过例子查询作为QBC 便利性的一部分，Hibernate支持通过例子查询（QBE）。使用QBE 的前提条件是应用程序支持具有某种属性值

62、集合（非默认值）的查询类实例。查询返回所有的匹配属性值的持久实例。QBE 不是特别强大的方法，但是对一些应用程序却很方便。下面的代码片断演示Hibernate的QBE：User exampleUser = new User();exampleUser.setFirstname(Max);QBE 的典型用例是允许用户指定属性值范围的查找屏幕，指定属性值范围用来匹配返回的结果集。这种功能在查询语言中很难清晰地表达，操纵字符串需要指定动态的约束集。QBC API和这种查询机制的例子将在第七章详细讨论。现在你知道Hibernate中基本的检索选项。我们在本节的剩余部分关注对象图的抓取策略。抓取策略定义

63、了用查询或装载操作检索对象图（或子图）的哪一部分。抓取策略传统的关系数据访问利用内连接和外连接检索相关的实体，用单个SQL查询抓取对某个计算所需要的所有数据。一些原始的ORM实现分开抓取数据，多次请求小块的数据，应用程序作为响应也会多次导航持久对象图。这种方法不能有效利用关系数据库的连接能力。实际上，这种数据访问策略将来很难扩展。ORM中的一个最困难的问题可能是最困难的是提供对关系数据库的有效访问，鉴于应用程序喜欢把数据当成对象图看待。对于我们经常开发的多种应用程序（多用户，分布式，web 和企业应用），检索对象时多次往返于数据库是不可取的。因此，我们讨论的工具比传统的工具更强调ORM中的R（关系）。有效地抓取对象图的问题已经通过在关联映射的元数据中指定关联级抓取策略解决了。这种方法存在的问题是每段代码使用一个需要不同集合的相关对象的实体。但是这是不够的我们需要的是支持细粒度的运行时关联抓取策略。Hibernate 两者都支持，允许在映射文件中指定默认的抓取策略，然后在代码运行时重载。Hibernate对于任何关联允许在四种抓取策略中选择，在关联元数据和运行时：立即抓取立