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

基于web的学生公寓管理系统的设计与实现毕业设计内容摘要：

ching object graphs efficiently (with minimal access to the database) has often been addressed by providing associationlevel 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 finegrained 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 remend 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 mon 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 提供下列方式 从数据库中提取对象： 导航对象图，从一个已经装载的对象开始，通过像 ().getCity()的属性访问器方法访问相关的对象。 如果 Session是打开的，当你导航图时， Hibernate会自动装载图的节点。 当对象的唯一标识符值是已知的时候，通过标识符检索是最方便最有性能的方法。 使用 Hibernate查询语言（ HQL），它是完全面向对象的查询语言。 使用 Hibernate 条件 API，它提供了类型安全的面向对象的方式执行查询而不需要操纵字符串。 这种便利性包括基于例子对象的查询。 使用本地 SQL查询，这种查询 Hibernate只关心把 JDBC 结果集映射到持久对象图。 在Hibernate 应用程序中，将结合使用这几种技术。 每一种检索方法可能使用不同的抓取策略— 那就是定义持久对象图的哪个部分应该检索的策略。 目标是在你的应用程序中为每个使用 场合发现最好的检索方法和抓取策略，同时最小化查询语句的数量以获得最好的性能。 在这一节我们不仔细讨论每个检索方法，相反，我 们将集中于基本的抓取策略和怎样调整Hibernate 映射文件以便对所有的方法达到最好的默认抓取性能。 在看抓取策略之前，我们将给出检索方法的概述。 （我们提到 Hibernate缓存系统但是将在下一章完全研究它。 ）让我们开始最简单的例子，通过给定的标识符值检索对象（导航对象图不加以说明了）。 在这一章的前半部分你已经看过一个简单的通过标识符检索的例子，但是还有许多需要知道。 根据标识符检索对象 下面的 Hibernate 代码片断从数据库中检索 User对象： User user = (User) (, userID)。 get()方法很特别，因为标识符唯一地标识类的单个实例。 因此，应用程序通常使用标识符方便地处理持久对象。 当用标识符检索对象时可以使用缓存，如果对象已经缓存了可以避免数据库碰撞（ hit）。 Hibernate也提供了 load()方法： User user = (User) (, userID)。 load()方法是旧的，因为用户的请求已经把 get()方法加入到 Hibernate API。 不同之处微不足道： 如果 load()方法不能在缓存或数据库中找到对象会抛出异常。 load()方法从不返回null。 如果对象没找到 get()方法返回 null。 load()方法返回代理而不是真正的持久实例。 代理是一个占位符，当第一次调用它时才装载真正的对象。 我们将在本节的后半部分讨论代理。 另一方面， get()方法从不返回代理。 在 get()和 load()之间选择很简单：如果你能确定持久实例存在，不存在将会认为是异常，那么 load()是很好的选择。 如果你不能确定给定的标识符是否有一个实例，使用 get()测试返回值，看它是否为 null。 使用 load()有更深的含义：应用程序可能检索一个对持久实例的引用（代理）而不会强制数据库检索它的持久状态。 因此，在缓存或数据库。