持久化框架ibatis、hibernate和Jpa优缺点分析

发布时间：2020-12-14 06:37:16 所属栏目：Java 来源：网络整理

导读：div style="font-family:Arial;font-size:14px;line-height:26px;color:rgb(67,67,67);" 简介 div style="font-family:Arial;font-size:14px;line-height:26px;color:rgb(67,67);" Java中的对象-关系映射是一项棘手的业务，诸如JDBC和实体bean一类的解决方案

<div style="font-family:Arial;font-size:14px;line-height:26px;color:rgb(67,67,67);">
简介
<div style="font-family:Arial;font-size:14px;line-height:26px;color:rgb(67,67);">
Java中的对象-关系映射是一项棘手的业务，诸如JDBC和实体bean一类的解决方案并未受到多大的欢迎，不过新一代的ORM解决方案倒是因此而出现了。这些工具使得编程更加的容易，并且是更加严格地遵循面向对象编程和多层次架构开发的理念。学习如何基于诸如查询语言支持、性能以及跨不同关系数据库的移植性等因素来比较Hibernate、iBATIS和Java Persistence API。
<div style="font-family:Arial;font-size:14px;line-height:26px;color:rgb(67,67);">

在本文中我们介绍并比较两种最流行的开源持久框架：和，我们还会讨论到（）。我们介绍每种解决方案并讨论其所规定的品质，以及在广泛的应用场景中其各自的长处和缺点。然后我们会基于诸如性能、移植性、复杂性以及对数据模型改变的适应性等因素来比较、和。

如果你是一个刚起步的程序员，新接触持久性概念的话，那么就把阅读此文当作是接受一次这一主题以及大部分流行的开源持久性解决方案的启蒙。如果你对这三种解决方案都很熟悉，并且只想要一个简单的比较的话，那么你会在“”一节中找到相应的内容。

持久性（）是数据的一个属性，其确保即使是在应用的生命周期之外数据也是可用的。对于像这样的面向对象语言来说，持久性确保了即使是在创建对象的应用停止执行之后对象的状态仍是可访问的。

存在多种实现持久性的方法。传统的解决这一问题的方法是使用文件系统来把需要的信息存储在平面文件（）中。这一方法很难用来管理大量的数据，因为数据分布在不同的文件中。使用平面文件系统的话维护数据的一致性也是一个问题，因为相同的信息可能会被重复放在各个文件中。在平面文件中查找数据很耗时，特别是如果这些文件还未排序的话。还有，文件系统对并发访问的支持有限，因为它们不能确保数据的完整性。基于上述种种原因，在寻求持久性时，文件系统并不被视为一个良好的数据存储解决方案。

当前最常见的方法是使用，其充当巨大量数据的存储库。存在许多种类型的数据库：关系型的、层次结构型的、网络型的、面向对象型的等等。这些数据库，以及它们的数据库管理系统（），不仅提供持久性能力，而且管理其所持久的信息。关系数据库是最被广泛使用的类型，关系数据库中的数据被建模成一组相互关联的表。

企业级应用的出现普及了层，其目的是通过把表现、业务和数据库相关代码分离到应用的不同层级（或是层面）中来提升可维护性。分离了业务逻辑和数据库代码的层面即是持久层，其保持了应用相对于底层的数据库技术的独立性。适当的位置上有了这一强健的层面，开发者就不再需要操心数据的持久性。持久层封装了存储和检索关系型数据库中的数据的方式。

应用传统上使用（）来把数据持久到关系数据库中。使用语句来完成创建（）、读取（）、更新（）和删除（）（）操作。代码内嵌在类中——换句话说，这类代码与业务逻辑紧密耦合在一起。这类代码还在很大程度上依赖于，而并非是跨数据库的标准；这使得从一种数据库移植到另一种数据库变得困难起来。

关系数据库技术强调的是数据及其之间的关系，而用于中的面向对象范式却并非关注数据本身，而是关注执行于数据之上的操作。因此，当这两种技术需要携手合作时，就会存在利益冲突。而且，关系数据库并不能满足继承、多态及关联这些面向对象编程概念。当应用中的用户定义的数据类型被映射到关系数据库上时，由这一失配导致的另一个问题就出现了，因为后者并没有提供所需的类型支持。

对象关系映射

对象关系映射（，）已成为了有时被称作对象关系阻抗失配（）的这一问题的一个解决方案。是一种透明地把应用对象持久到关系数据库中的表的技术。的行为就像是一个虚拟的数据库，对用户隐藏了底层的数据库架构。提供功能来执行完整的操作并鼓励面向对象的查询。还支持元数据映射以及在应用的事务管理方面提供帮助。

举个例子有助于说明是如何工作的。考虑一个需要持久到数据库中的简单的对象，领域模型中的这一对象是数据模型中的表的表现形式。对象的属性派生自表的各列。在类和表之间存在一个直接映射，如图中的说明。

<p align="center">图<span style="font-family:'Times New Roman';">1.?把对象映射到表上

存在许多开源的工具，其中包括、以及等。这些工具大多数是提供应用和数据库之间的抽象层的持久性框架。持久性框架把应用领域中的对象映射成需要持久在数据库中的数据，这些映射可使用文件或是元数据注解（后者作为的组成部分被引入到语言中）来定义。持久性框架的目的是分离数据库相关代码和应用代码（即业务逻辑），从而提高应用的灵活性。持久性框架通过提供一个持久性逻辑的包装器来简化开发过程。

完成了持久性的基本介绍之后，我们就做好了继续讨论两种最流行的开源持久框架和的准备。我们还会介绍，并讨论这三种解决方案在各种应用场景中的优势和弱点。

：直接使用

对象关系映射（）使用直接映射来生成内部的或是代码。然而对于一些应用场景来说，你需要对查询做更加直接的控制。在编写涉及了一系列更新查询的应用时，直接编写自己的查询比依赖于生成的来得更有效一些。另外，在对象模型和数据模型之间存在失配时，是不能够使用的。正如我们提到过的那样，代码一度是这类问题最常见的解决方案，但是它在应用代码内部引入了许多的数据库代码，使得应用更加难以维护。这里需要一个持久层来解耦应用和数据库。

框架有助于解决这些问题。是一个持久性框架，其提供了的好处却又免去了的复杂性。与其他大多数的持久性框架不同，鼓励直接使用，并确保所有的好处没有被框架本身覆盖掉。

简单是最大的优势，因为它提供一个简单的映射和用于构建数据访问代码的层。在这一框架中，数据模型和对象模型不需要做精确的彼此映射。这是因为使用了一个数据映射器（），其经由一个描述符而不是元数据映射器把对象映射到存储过程、语句或是上，而元数据映射器起的是把领域中的对象映射到数据库中的表上的作用。因此，能够使得数据模型和对象模型彼此独立，互不相干。

项目最初由发起并在年发布。这一持久性框架最初是为设计的，然而后来已经被扩展以支持其他的平台，这其中包括和。

iBATIS的工作方式

通过把数据库的输入输出映射到领域对象上来支持数据库和应用之间的松散耦合，并由此而引入了一个抽象层。映射是通过使用包含了查询的文件来完成的。这一松散耦合允许映射在应用和数据库设计失配的系统上工作，它还有助于用来处理传统遗留数据库和随时间发生变化的数据库。

框架主要使用下面的两个文件作为描述符：

????????????

我们会仔细地研究每个文件。

是一个主要的文件，其包含所有的配置细节，比如数据源这一类的数据细节等；它还可以选择在其中包含关于事务管理的信息。该文件标识了所有的文件——可能有不止一个这样的文件——并加载它们。

考虑这样一个映射到数据库中的表上的类，类的属性——、和——对应于表中的相似名字列。类的类图如图所示。（该类会被用来说明本文中讨论的不同的持久性技术。）

图类的类图

类的文件可以写成清单所示的内容。

清单类的文件

使用标签来配置给这一特定的映射使用的数据源。其指定数据源的类型以及一些细节，其中包括驱动程序、数据库以及用户名称和用户密码等信息。标签则指定文件的位置，以便加载它。

另一个文件是，该文件在其相关到某个表后再做实际命名。在单个应用中可能就会存在任意数量的这种文件，这一文件是把领域对象映射到语句的地方。这一描述符使用参数映射来把输入映射到语句上，并使用结果映射来映射的。该文件还包含了查询，因此，要改变查询的话，你需要修改的是而非应用的代码。映射是通过使用实际的要和数据库交互的语句来完成的。所以，使用给开发者提供了更大的灵活性，并使得对于有使用编程经验的人来说变得更容易理解。

定义了在表上执行操作的语句的文件如清单所示。

清单用于在上执行操作的

在清单中，标签被用来表示类型的别名，这样就可以避免在每次类名出现的时候都要输入完整的类名。其包含了标签，该标签描述了从查询中返回的列和类所表示的类属性之间的映射。是可选的，如果表（或别名）中的列与类属性完全匹配的话就不需要。跟在这一标签后面的是一系列的查询，可以包含任意数目的查询。所有的这些、、和语句都写在各自的标签内部，每个语句都使用属性来命名。

来自查询的输出可以映射到一个或是一个结果类上。查询中的别名应该与目标结果类（即该）中的属性相匹配。属性被用来指定其属性作为输入的，这一哈希符号内的任何参数都是该的属性。

应用中

在完成了整个的配置和在两个文件中都做了映射之后，文件需要由应用来加载。第一步是加载早先创建的配置文件，要做到这一点的话，你需要用到类，该类已包含在框架中，如清单所示。

清单加载

类用来与一起工作，其允许运行诸如、、一类的已映射语句。对象是线程安全的，因此，一个对象就足够了，这也使得把它用作一个静态成员成为了一种不错的选择。该对象通过读入一个文件来创建，框架提供了这一实用方法，你可以使用该方法来读入文件。因此，通过使用的这一实例，你可以访问来自数据库的对象——在这一例子中，是对象。

为了调用针对表的操作，提供了不同的方法，比如其中就包括、、、和等。清单中展示的方法返回对象的一个列表。

清单

同样地，当只有一行内容作为查询结果返回时，应该使用方法。这两个方法都使用语句名作为参数。

相应的方法可用于执行、和操作，如清单所示。这些方法既要用到文件中声明的语句名，也要用到对象作为输入。

清单、和操作

这样，对象就可以使用对象中的直接的语句来持久化了。

何时使用iBATIS

最好是用在你需要全面地控制的时候，在需要对查询做微调的时候也很有用。当你在应用和数据库设计两方面都有完全的控制权的时候，就不应该使用，因为在这样的情况下，应用可能会做出修改以适应数据库，或是反过来。在这种情形中，你可以构建一个完全的对象关系应用，其他的工具更适于使用，因为较为以为中心，其通常被称作反转的——功能齐全的工具生成，而直接使用。也不适合于非关系型的数据库，因为这类数据库不支持事务和其他用到的键特性。

是一个开源的轻量级的对象关系映射解决方案。的主要特点是支持基于对象的建模，这使得它可以提供一个透明的持久性机制。其使用来把数据库映射到应用上，并且支持细粒度的对象。的当前版本是，该版本支持注解（），因此是满足规范的。

包含了一种被称作或是的非常强大的查询语言。非常类似，不过还定义了一些额外的约定。是完全面向对象的，能够充分利用继承、多态和关联等这些面向对象核心概念的长处。除了被用到的类和属性的名称之外，查询是非大小写敏感的。把查询结果作为对象返回，这些对象可以由编程者直接访问和操纵。还支持分页和动态分析（）等许多高级功能，一直未提供对这些功能的支持。在用到多个表来工作时，并不要求做任何显式的连接（）。

是由带领的一个团队开发出来。的开发始于年，该团队后来被收购，现由管理。最初是为开发的；在年引入了命名为的版本。

为什么我们需要Hibernate?

传统上用于对象关系映射的实体（）非常难以理解和维护，使得对象关系映射变得简单起来，它的方法是在一个文件中映射元数据，该文件定义了需要映射到某个特定类上的数据库中的表。在其他的持久性框架中，你需要修改应用类来实现对象关系映射；而在中则不需要这样做。

使用了后，你就无需担心数据库的改变，因为手工修改脚本文件的工作已被免除。如果你需要不时改变应用使用到的数据库的话，也可以通过修改配置文件中的属性来很容易地解决这一问题。提供了全部的功能，其中的有些是早先的商业框架一直没有提供的。也支持许多的数据库，其中包括、、、和等，而且也能够与基于简单对象（，）的模型配合得很好。

基于所选择的底层数据库来生产代码，因此省去了编写代码的麻烦，它还支持连接的池化。使用的很简单也很容易学习，只有很少知识的开发者也能够使用，因为它减轻了编写查询的负担。

Hibernate架构

就内部来说，用到了，提供了数据库的一个抽象层，它同时也采用了（）和来集成其他应用。需要用来与数据库交互的连接信息由连接池提供，这需要做配置。

的架构主要由两个接口——和组成——以及一个接口，该接口位于应用的持久层中。定义于应用的业务层中的类通过持久层的独立元数据来进行交互，持久层转而使用某些来与数据库层对话。此外，还用到了其他的配置接口，其中主要是有着适当命名的类。还使用回调接口和一些用于扩展映射功能的可选接口。完整的架构如图所示。

图架构：全貌

下面是组成部分的主要编程接口：

????????????基本上是用来获取一个实例，并且可看作是连接池化机制的一个模拟。这是线程安全的，因为所有的应用线程都使用单一的（只要只使用一个数据库）。该接口通过配置文件来配置，配置文件决定了要加载的映射文件。

????????????提供了一个单独的线程，该线程确定应用和数据库之间的对话。这是对一个特定（单个）连接的模拟。该接口是非常轻量级的，而且是非线程安全的。

????????????提供了一个单线程对象，其横跨整个应用并确定原子工作单元。其基本上抽象了、和事务。

????????????被用来执行查询，或以的形式或是以底层数据库的方言形式。实例是轻量级的，需要提到的很重要的一点是，它不能用在创建它的的外部。

配置Hibernate

通过一个名为的文件来做配置。该配置文件提供建立到特定关系数据库的连接方面的帮助，配置文件应该要知道其需要引用哪些映射文件。在运行时，读入映射文件，然后使用映射文件来构建一个动态的与数据库表相对应的类。一个示例的配置文件如清单所示。

清单

使用Hibernate工作

当在应用中创建了一个实例时，读入配置文件并标识出各自的映射文件。创建自的对象获取到数据库的一个特定连接，这个对象就是持久化类实例的持久化上下文。实例可以是以下三种状态之一：瞬态的（）、持久的（）或是游离的（）。处于瞬态时，对象尚未与表关联起来；处于持久态中时，对象是与表关联的；而处于游离态中时，则不能保证对象与表是同步的。用来持久一个对象的代码如清单所示。

清单使用来持久一个对象

配置文件标识的映射文件把某个特定的持久类映射到数据库表上。它把特定的列映射到特定的字段上，并且具备关联、集合、主键映射以及键生成机制。映射文件一般根据其映射到表来命名，在我们的示例应用中，你应该使用作为对应于表的文件的名称。如你在清单中见到的那样，映射文件指定类需要映射到数据库中表上，该表有名为、和的三列，是主键，必须要赋予某个值。

清单

何时使用Hibernat

最适合用来作为端到端的映射的手段。其提供了一个完整的解决方案，但但是不会让你控制查询。对于那些对应用和数据库两者都有完全的控制权的情况来说，是一种理想的解决方案。在这类情况中，你可以修改应用来适用数据库，反之亦然，在这些情况下你可以使用来构建一个全对象关系应用。对于不太熟悉的面向对象编程者来说，是最佳选择。

是平台上的标准的对象关系映射和持久管理接口。作为规范成果的一部分，它得到了所有主要的供应商的支持。借鉴了诸如、、（）以及容器托管持久化等领先的持久性框架的想法。提供了一个平台，持久性提供程序（）可在该平台上获得使用。的一个主要特性是任何的持久性提供程序都可以在上面做插拔。

是一个基于的标准的持久化模型。它是规范的组成部分，代替了实体。实体被定义成规范的一部分，但其作为一个完整的持久性解决方案却未能打动业界，主要是因为这几方面的原因：

????????????实体是重量级组件且与服务器紧密耦合，这使得它们相比于轻量级的来说更缺乏适应性，对于可重用性来说，更加理想。

????????????实体难以开发和部署。

????????????实体强制使用，而实体则高度依赖服务器的配置和声明，这些限制将会影响到应用的性能。

为了解决这些问题，软件专家组制定了，其作为的组成部分。从其他的持久化技术那里借用了最好的想法，其为所有的应用定义了一个标准的持久化模型。既可用作应用也可用作应用的持久化解决方案。

使用元数据注解和或描述符文件来配置应用领域中的对象和关系数据库中的表之间的映射。是一个完整的解决方案，并且支持继承和多态。它还定义了一种类的查询语言：（），该种语言不同于（），是由实体使用的一种语言。

使用，你就可以插入任何实现了规范的持久性提供程序，而不是随容器一起提供的缺省的持久性提供程序是什么就用什么。例如，服务器使用提供的作为它的缺省持久性提供程序，但是你可以通过在应用中包含所有必须的文件来选择使用作为持久性提供程序。

刚刚才了解了如何用作一个独立的持久化方案，你可能会因发现它也能与一起工作而感到奇怪。严格来讲，如果你打算直接使用的话，那么你要使用的就是这一模块，该模块使用无需处理对象的生成；应用依然独立于数据库。可和任何的应用服务器一起使用，以及可用在任何普通的需要实现对象关系映射的应用中，这一映射通过使用原生的、和映射来实现。

团队积极投身到规范的制定中，在引入了之后，持久性的一个独立实现被作为的一部分提供——和，这两部分都构建在之上。对于使用做开发的应用来说，在中需要使用，因此可考虑作为持久性提供程序的一个选择，使用做开发的应用会利用来和一起工作。

使用JPA工作

用到了版本提供的包中定义的许多接口和注解类型。使用与数据库中的表做映射的实体类（）。这些实体类使用注解来做定义。清单给出了名为的实体类，其对应于例子应用的数据库中的表。

清单实体类

实体类的特性如下：

????????????实体类使用这一注解（）来进行注释。

????????????其必须有一个公有的或是受保护的未带参数的构造函数，也还可以包含其他的构造函数。

????????????其不能声明成的。

????????????实体类可继承于其他的实体类和非实体类，反过来也是可以的。

????????????其不能有公有的实例变量，应该只能使用公有的和方法来暴露类成员，遵循的风格。

????????????实体类，作为，一般来说不需要实现任何特定的接口，然而，如果其被作为参数在网络间传递的话，它们就必须要实现接口。

这一注解指定了该实体实例所映射的表的名称。类成员可以是原始类型的、原始类的封装器、枚举类型的或是其他可嵌入的类。到表的每列的映射使用这一注解来指定。这一映射可用在持久域上，在这种情况下，实体使用持久域，映射也可用在方法上，在这种情况下实体使用持久属性。不过对于某个特定的实体类来说，其必须要遵循同一种约定。此外，使用进行注释的域或是标记为的域不会被持久到数据库中。

每个实体都有一个唯一的对象标识符，该标识符用来区分应用领域中的不同实体实例；其对应于定义在相应表中的主键。主键可以是简单的或是复合的。简单主键使用这一注解来进行注释，复合主键可是单个的持久属性域或是一组这样的域属性；它们必须定义在一个主键类中。复合主键使用和这两个注解来进行注释，任何主键类都应该要实现和方法。

实体的生命周期由实体管理器进行管理，实体管理器是的一个实例。每个这样的实体管理器都和一个持久化上下文相关联。该上下文可被传播至所有的应用组件中，或是由应用来做管理。可在应用中使用来创建，如清单所示。

清单创建

表示用来创建的持久单元的名称。还可使用这一注解来在应用组件之间做传播。在清单的方法中，一个新的雇员记录被插入到了表中，一旦与关联的执行完成，实体实例表示的数据就被持久到数据库中。也定义静态的和动态的查询来从数据库中检索数据，静态查询使用这一注解来编写，如在这一实体类中展示的那样。动态的查询则使用的方法直接在应用中定义。

结合使用基于注解的和基于的配置。用于此目的的文件是，该文件位于应用的目录下。该文件定义了应用用到的所有持久单元，每个持久单元都定义了被映射到某单个数据库上的所有实体类。应用的文件如清单所示。

清单

该文件定义了一个名为的持久单元，相应数据库的配置也包含在这一持久单元中。一个应用可以配有多个关联到不同数据库的持久单元。

总而言之，为应用和应用提供了一个标准的基于的解决方案，其使用实体类、实体管理器和持久单元来映射和持久领域对象和数据库中的表。

何时使用JPA

应该用在需要标准的基于的持久性解决方案的时候。支持继承和多态这两种面向对象编程特性。的缺点是其需要一个实现了其自身的提供程序。这些供应商特有的工具还提供了某些并未定义成规范组成部分的特性，其中一个这样的特性是缓存支持，该功能并未在中做明确定义，但其中一个最流行的实现了的框架对这一功能提供了很好的支持。

此外，被定义成只能在关系数据库上工作。如果你的持久化解决方案需要扩展到其他类型的数据存储上，比如数据库上的话，则就不能够用来解决你的持久性问题了。

现在你已经分析了三种不同的持久化机制及其运作方式。这些框架中的每一种都有自己的优点和缺点。让我们来考虑几个参数，这些参数可帮助你确定其中满足你需求的最佳可行方案。

简易性

在许多应用的开发中，时间是主要的制约因素，特别是当团队成员需要经培训来使用某种特定框架的时候。在这类情形中，是最好的选择，该框架是三种框架中最简单的，因为它仅需方面的知识就够了。

完整的ORM解决方案

像和一类的传统的解决方案应该用来作为一种完全的对象关系映射手段。和直接把对象映射到数据库表上，而则是把对象映射到查询的结果上。在某些应用中，领域模型中的对象是根据业务逻辑来设计的，可能不完全与数据模型匹配，在这种情况下，是合适的选择。

对SQL的依赖

总是会存在精通的人和更信任的人这样的一种划分，对于一个熟练的程序员来说，他想使用一个无需与有太多交互的持久性框架，那么是最好的选择，因为它会在运行时生成高效率的查询。但是，如果你想要使用存储过程来对数据库查询做各方面的控制的话，则是推荐的解决方案。还可通过的方法来支持。

支持的查询语言

大力支持，而和则是使用它们自己的查询语言（分别是和），这些语言与类似。

性能

一个应用要成功的话需要具备良好的性能。通过提供缓存设施来提高性能，这些缓存设施有助于更快地从数据库中检索数据。使用查询，这些查询可通过微调来获得更佳性能。的性能则取决于供应商的实现，根据每个应用的特有情况做选择。

跨不同数据库的移植性

有时候，你需要改变应用使用的关系数据库，如果你使用来作为持久化解决方案的话，那么这一问题很容易解决，因为在配置文件中使用了一个数据库方言属性。从一个数据库移植到另一个数据库上仅是把属性修改成适当值的事。使用这一属性来作为生成特定于某种给定数据库的代码的指南。

如前所述，要求你编写自己的代码，因此，应用的可移植性取决于这些。如果查询是使用可移植的编写的话，那么也是可在不同的关系数据库之间做移植的。另一方面，的移植性则取决于其正在使用的供应商实现。是可在不同的实现之间做移植的，比如和之间。因此，如果应用没有用到某些提供商特有的功能特性的话，那么移植性就不是什么大问题。

社区支持和文档

在这方面，明显是个赢家。存在许多以为焦点的论坛，在这些论坛中社区成员都会积极地回答各种问题。关于这一点，和正慢慢赶上。

跨非Java平台的移植性

支持和。以的形式为提供了一个持久性解决方案。，作为特定于的，显然并不支持任何的非平台。

表给出了这一比较的一个总结。

表持久性解决方案比较

特性

简易性

优

良

完整的解决方案

一般

优

对数据模型改变的适应性

良

一般

复杂性

优

一般

对的依赖

良

一般

性能

优

不适用

跨不同关系数据库的移植性

一般

优

不适用

非平台的移植性

优

良

不支持

社区支持和文档

一般

良

对这些特性的支持取决于持久性提供程序，最终的结果可能会视情况各异。

、和是用于把数据持久到关系数据库中的三种不同的机制，每种都有着自己的优势和局限性。不提供完整的解决方案，也不提供任何的对象和关系模型的直接映射。不过，给你提供了对查询的全面控制权。提供了一个完整的解决方案，但不提供对查询的控制权。非常的受欢迎，有一个庞大而活跃的社区为新用户提供支持。也提供一个完整的解决方案，并提供对诸如继承和多态一类的面向对象编程特性的支持，不过它的性能则取决于持久性提供程序。

某个特定持久性机制的选择事关所有功能特性的权衡，这些特性在本文的比较章节中都做了讨论。对于大部分的开发者来说，需要根据是否要求对应用的做全面控制、是否需要自动生成，或仅是想要一个易于编程的完整的解决方案等各方面的考虑来做决定。

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!