基于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 & Sons Inc.2003
[10] 史济民.软件工程―原理.方法与应用[M].高等教育出版社.2002
[11] Charles Bell. Mats Kindahl. Lars Thalmann. MySQL High Availability: Tools for Robust Data Centers. O'Reilly Media.2010

指导教师签字：
教研室主任签字：
　　　　　　　　　　　　　　　　　　　　　　　　 年 月 日
大连交通大学信息工程学院
毕业设计(论文)进度计划与考核表
学生姓名
方广志
专业班级
软件工程
08-3班
指导教师
阎树昕
王丽娟
本课题其他人员
无
题　目
基于web的学生公寓管理系统的设计与实现
日　期
计划完成内容
完成情况
指导老师检查签字
第1周
拟订《毕业论文进度计划与考核表》

第2周
完成实习或调研报告

第3周
提交外文文献翻译资料

第4周
系统概要设计阶段

第5周
系统详细设计阶段

第6周
系统编码实施、完成论文初稿

第7周
完成系统编码实施

第8周
系统编码调试、提交论文初稿

第9周
完成系统编码调试、完善毕业论文

第10周
完成撰写毕业设计论文编写及代码测试

第11周
完成论文终稿、准备毕业论文打印、装订

第12周
提交毕业论文终稿及代码

第13周
完成毕业论文

第14周
毕业论文答辩

指导教师签字：　　　　　　　　　　　 　　年　　月　　日

注：“计划完成内容”由学生本人认真填写，其它由指导教师考核时填写。

大连交通大学信息工程学院
毕业设计(论文)外文翻译

学生姓名 方广志 专业班级 软件工程08-3班
指导教师 阎树昕　王立娟 职 称 高工　讲师
所在单位 信息科学系软件工程教研室
教研室主任 　 刘瑞杰

完成日期 2012 年 4 月 13 日
Hibernate In Action

Retrieving objects
Retrieving persistent objects from the database is one of the most 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().getCity(). 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), 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 care of mapping the JDBC result sets to graphs of persistent objects.In your Hibernate applications, you’ll use a combination of these techniques.Each retrieval method may use a different fetching strategy—that is, a strategy that defines what part of the persistent object graph should be retrieved. The 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 won’t discuss each retrieval method in much detail in this section; 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 r