当前位置： →
→ 谈一下对Hibernate的理解转
谈一下对Hibernate的理解转
& 作者：佚名 & 来源： 互联网 & 热度：
&收藏到→_→：
摘要: 谈谈对Hibernate的理解(转) 一、Hibernate是JDBC 的轻量级的对象封装，它是一个独立的对象持久层框架，和App Server，和EJB没...
"谈一下对Hibernate的理解转"：：
谈谈对hibernate的理解(转)
一、hibernate是jdbc 的轻量级的对象封装，它是一个独立的对象持久层框架，和app server，和ejb没有什么必然的联系。hibernate可以用在任何jdbc可以使用的场合，例如java的访问代码，dao接口的实现类，甚至可以是bmp里面的访问的代码。从这个意义上来说，hibernate和eb不是一个范畴的东西，也不存在非此即彼的关系。 二、hibernate是一个和jdbc密切关联的框架，所以hibernate的兼容性和jdbc驱动，和都有一定的关系，但是和使用它的java程序，和app server没有任何关系，也不存在兼容性问题。 三、 hibernate不能用来直接和entity bean做对比，只有放在整个j2ee项目的框架中才能比较。并且即使是放在软件整体框架中来看，hibernate也是做为jdbc的替代者出现的，而不是entity bean的替代者出现的，让我再列一次我已经列n次的框架结构： 传统的架构： 1) session bean &-& entity bean &-& db 为了解决性能障碍的替代架构： 2) session bean &-& dao &-& jdbc &-& db 使用hibernate来提高上面架构的开发效率的架构： 3) session bean &-& dao &-& hibernate &-& db 就上面3个架构来分析： 1、内存消耗：采用jdbc的架构2无疑是最省内存的，hibernate的架构3次之，eb的架构1最差。 2、运行效率：如果jdbc的代码写的非常优化，那么jdbc架构运行效率最高，但是实际项目此文来自: 马开东博客
转载请注明出处 网址：
中，这一点几乎做不到，这需要非常精通jdbc，运用 batch语句，调整preapredstatement的batch size和fetch size等参数，以及在必要的情况下采用结果集cache等等。而一般情况下是做不到这一点的。因此hibernate架构表现出最快的运行效率。 eb的架构效率会差的很远。 3、开发效率：在有jbuilder的支持下以及简单的项目，eb架构开发效率最高，jdbc次之，hibernate最差。但是在大的项目，特别是持久层关系映射很复杂的情况下，hibernate效率高的惊人，jdbc次之，而eb架构很可能会失败。 4、分布式，安全检查，集群，负载均衡的支持 由于有sb做为facade，3个架构没有区别。
搜索此文相关文章：此文来自: 马开东博客
网址: 站长QQ
上一篇：没有了
谈一下对Hibernate的理解转_软件架构设计相关文章
软件架构设计_总排行榜
软件架构设计_最新
软件架构设计_月排行榜
软件架构设计_周排行榜
软件架构设计_日排行榜&&&&谈谈对软件架构的认识
&谈谈对软件架构的认识
这是一个PPT文件，有些内容是来自网上，再此感谢，有些内容是我的原创。
若举报审核通过，可奖励20下载分
被举报人：
举报的资源分：
请选择类型
资源无法下载
资源无法使用
标题与实际内容不符
含有危害国家安全内容
含有反动色情等内容
含广告内容
版权问题，侵犯个人或公司的版权
*详细原因：
VIP下载&&免积分60元/年（1200次）
您可能还需要
Q.为什么我点的下载下不了，但积分却被扣了
A. 由于下载人数众多，下载服务器做了并发的限制。若发现下载不了，请稍后再试，多次下载是不会重复扣分的。
Q.我的积分不多了，如何获取积分？
A. 获得积分，详细见。
完成任务获取积分。
论坛可用分兑换下载积分。
第一次绑定手机，将获得5个C币，C币可。
关注并绑定CSDNID，送10个下载分
下载资源意味着您已经同意遵守以下协议
资源的所有权益归上传用户所有
未经权益所有人同意，不得将资源中的内容挪作商业或盈利用途
CSDN下载频道仅提供交流平台，并不能对任何下载资源负责
下载资源中如有侵权或不适当内容，
本站不保证本站提供的资源的准确性，安全性和完整性，同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。
课程资源下载排行
您当前C币：0&&&可兑换 0 下载积分
兑换下载分:&
消耗C币:0&
立即兑换&&
兑换成功你当前的下载分为 。前去下载资源
你下载资源过于频繁，请输入验证码
如何快速获得积分？
你已经下载过该资源，再次下载不需要扣除积分
谈谈对软件架构的认识
所需积分：3
剩余积分：0
扫描微信二维码精彩活动、课程更新抢先知
VIP会员，免积分下载
会员到期时间：日
剩余下载次数：1000
谈谈对软件架构的认识
剩余次数：&&&&有效期截止到：
你还不是VIP会员VIP会员享免积分 . 专属通道极速下载
VIP下载次数已满VIP会员享免积分 . 专属通道极速下载，请继续开通VIP会员
你的VIP会员已过期VIP会员享免积分 . 专属通道极速下载，请继续开通VIP会员对软件架构的认识研究报告_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
对软件架构的认识研究报告
上传于||文档简介
&&对​软​件​体​系​结​构​的​认​识
阅读已结束，如果下载本文需要使用0下载券
想免费下载更多文档？
定制HR最喜欢的简历
下载文档到电脑，查找使用更方便
还剩4页未读，继续阅读
定制HR最喜欢的简历
你可能喜欢在我们刚开始学习架构的时候，首先会想到分层的概念，分层架构比较经典的是三层架构，那么，什么是三层架构呢？它包括表现层，业务层，数据访问层；而对于一个新手来说，从抽象意义上的三层架构，逻辑上就划分为三个层。
这个是最基本的三层架构模式。
表现层充当系统的界面呈现以及UI逻辑的角色，也就是说，UI（用户界面）属于表现层；
举一个对于asp.net WebForm来说，人们喜欢把对于UI的控制逻辑（服务器控件的读取、设置、事件等等）写在页面的后置隐藏代码中，并且依赖业务逻辑层。当然，服务器控件支持数据绑定的功能，可以通过数据源进行绑定控件。这样就可以节省在后置隐藏中的代码。
因此，我们就可以把表现层分为UI用户界面以及UI逻辑：
UI用户界面的职责只是作为数据输入和输出后的展示工作。
UI逻辑的职责是负责业务逻辑层以及UI用户界面之间的数据交互，并且尽可能地让UI逻辑不依赖于UI技术。
其中UI用户界面的实现方式有很多，包括ASP.NET，WinForm，WPF，Silverlight，移动Web，智能设备等等。
将表现层中UI页面和UI逻辑分离的策略中，当前使用最多的两种模式是MVC模式和MVP模式。
MVC模式，即模型-视图-控制器模式，通过视图触发并执行某个操作，调用控制器，通过控制器去操作业务层，最终返回模型，在视图中进行展示。这里的模型可以是一个领域模型（DM），也可以是一个数据迁移对象（DTO）。
MVP模式，即模型-视图-展示器模式，和MVC模式有点像，不同的是MVP中视图和模型是被完全分离出来的，视图中定义一个接口，而展示器通过调用该接口的方法以控制视图。因此，视图和模型是松散的，展示器也充当了一个控制器的角色，同时它也不依赖于UI技术。
另外再介绍一种模式PM（Preentation Model），它可以说是MVP的变体，在PM中，视图不定义接口，这里的模型只是表示视图状态的类，视图中的元素被直接绑定到模型属性上。例如在WPF中，WPF就先天的具有数据双向绑定机制以及事件通知属性机制。
所以它特别适用于WPF，Sliverlight等等。
在开始业务层之前,不得不说一个前提,在一个小型项目中,直接让表现层调用业务层,足以解决所有问题。但是，当项目大到使用多种表现形式，如使用了各种UI技术，ASP.NET，WPF，移动设备等等，就要考虑在你的表现层和业务层之间增加一个层，以至于让表现层和业务层解耦，因为业务层作为一个业务中间件的平台，最好不要暴露于表现层中，这个层就是传说中的服务层。架构图又演化为：
服务层实际上并不执行任何具体的工作，其功能在于组织各个业务对象,服务层将业务层所有的细节对表现层都隐藏起来,服务器将组织业务逻辑层中的组件,并且通过数据迁移对象(DTO)与表现层交互,因此就产生一个DTO模型。
为了实现服务的可重用性，需要使用服务接口，表现层通过规定的接口访问功能。服务的实现继承服务接口，而服务的实现专注于业务层的调用。
对于服务层，常用的方法包括Web服务、.NET Remoting、Rest以及WCF技术。
本人比较建议使用WCF作为服务，因为可以方便地通过配置达到远程调用服务的目的。
服务层消除了两个表现层和业务层之间的耦合，服务层可以实现一个远程接口，达到多UI技术甚至多平台上的通信。
当然增加服务层也有缺点，假如使用WCF服务，会增加系统的调用开销，进而影响性能。
业务层中包含系统所需要业务过程上的实现，并与下层的数据访问层交互。
我们通常也叫做业务层叫做业务逻辑层，但我认为业务逻辑层是属于业务层的一方面，业务逻辑更专注于业务上逻辑算法的实现。因为业务层还可以包括其他的方面。
业务层必须包括对业务实体尽心建模的对象模型，表达了客户的所有策略和需求的业务规则，因此就产生了领域模型。
（PS：如果这里你不使用领域模型，那么需要采用业务规则层进行业务功能上的业务规则的验证和控制）
领域模型包括对实体的属性定义，方法定义以及实体与实体之间的关系。从这个角度上看，UML建模至关重要，通过对UML动态图和静态图的描述，可以映射到领域模型中。
从服务层刚才讲到了DTO模型，这里需要一个机制将DTO转化为领域模型，所以产生了DTO映射层（DTOMapper）。
另外业务层还包括核心中间件技术，包括第三方组件，以及工作流引擎等等。
业务层需要考虑到一些与数据访问层交互的设计模式，模式中包括事物脚本模式、表模块模式、活动记录模式、领域模型模式。
事物脚本模式是通过方法来执行业务流程，它是一个过程式模型，事物脚本的每个方法都有一个特定的事物脚本，它侧重于业务上一系列流程上的顺序操作，它实现起来很简单，但是它有个致命的缺点就是它会造成很多重复的代码。
表模块模式比起事物脚本模式，具有一定的结构，它的思想也很简单，每个数据表都定义一个业务组件（实体类，实体操作类），在.NET中更多的使用DataSet作为表模型的数据交互。但是它也有一个缺点就是它是从数据库驱动它不适合于大量的数据表以及数据表之间的复杂关系。
活动记录模式中的对象中，可以包含数据和方法。它接近于数据表的结构，它的对象中执行方法中可以包含CRUD操作，验证算法，以及其他的计算功能。一般来说，领域模型不是太复杂，活动记录模式是个好选择。当然他也存在问题，同样地，它对于复杂的业务上，维护的成本也很高，并且如果需求变更导致数据库修改，就需要调整记录对象模型中的相关代码。
经典应用：LINQ-TO-SQL以及Castle ActiveRecord。
领域模型模式是从领域驱动设计中衍生来的，它是以业务为核心的设计模式。它对于复杂的业务逻辑，相当适用。前三种方式使用的是以数据驱动方式，数据驱动方式特点简单，但是当系统到了一定的规模后，就会到难以维护的程度。
数据访问层的目的很明确,主要作为提供数据持久化的功能，包括数据的读取和写入，另外还必须包括事务处理，并发控制等等。
操作数据库的方法可以有两种方式,ORM方式，ADO.NET方式。
ORM可以采用一些第三方的ORM框架来实现，ADO.NET采用ASP.NET自带的数据库操作来实现。
不同的数据库具有不同的持久化实现，因此这里添加一个存储仓库接口层，来适应不同的数据库实现，这里你可以使用IOC依赖注入方式进行数据库选型，可以利用Unity、Spring.NET、Castle的IOC容器等等。
最后各个层中都可以依赖于公共基础设施层。
公共基础设施层可以包括Common通用模块，Logging日志模块，Exception异常模块，Configuration配置模块，DI依赖注入模块，单元测试模块以及第三方组件（例如NHibernate、Sprint.NET、Castle、Quartz计划任务等等）
总结：项目类型、项目规模以及业务上的需求，都影响着系统架构的设计，系统架构并不是一层不变的，没有最好的架构，只有更好的架构，并且从项目中多思考系统的扩展性。文中对于架构的分析，只是从通常的角度上去考虑，在项目中，您还需要根据实际情况去做调整。
谢谢大家阅读！
阅读(...) 评论()}