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

《基于web的学生公寓管理系统的设计与实现毕业设计(论文).doc》由会员分享，可在线阅读，更多相关《基于web的学生公寓管理系统的设计与实现毕业设计(论文).doc（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 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