码迷,mamicode.com
首页 > 其他好文 > 详细

MyBatis知多少(6)表现层与业务逻辑层

时间:2015-07-13 20:27:22      阅读:115      评论:0      收藏:0      [点我收藏+]

标签:

技术分享

 

 

 

 

 

 

 

 

 

 

 

 

 

表现层

  表现层负责向最终用户展示应用程序的控制方式以及数据。它还要负责所有信息的布局和格式。今天,商业应用程序最流行的表现方式应该算是Web前端了,它使用HTML和JavaScript并通 过Web浏览器来满足用户的界面外观需求。

  Web应用程序的优势包括跨平台兼容性、易部署和可扩展。amazon.com就是Web应用程序的—个极好的例子,它允许你在线购书。这就是Web应用程序的一个绝佳应用,因为不可能要求用 户为了买一本书而去下载一个应用程序。

  当需要高级的用户控件或者复杂的数据操纵时,Web应用程序通常就无法胜任了。在这些情况下,使用本机操作系统小部件(如tab、table、treeView和嵌入式对象)的富客户端就体现出了 它的优势。富客户端允许一个强大得多的用户界面,但它往往更难部署,且要达到与Web应用程序相同级别的性能和安全性需要开发人员花费更多的精力。富客户端技术的例子包括Java的Swing等。

  最近,Web应用程序和富客户端这两个概念被混合了起来,形成了所谓的“混合型客户端”, “混合型客户端”试图同时获得Web应用程序和富客户端两者的优点。一些非常小且使用了一些髙级控件的富客户端可能通过Web浏览器被悄悄地下载到用户的桌面。这个混合型的富客户端不包含任何业务逻辑,甚至可能连用户界面的布局都不是内建好的。相反,应用程序的界面外观以 及可用的业务功能都是通过一个Web服务,或者把XML用作客户端与服务器间接口的Web应用程序来配置的。这种方式唯一的缺点就是开发和部署这样的应用程序需要额外的软件。

  接下来当然就有了所谓混合型表现层的典型案例,即Ajax。它曾经是Asynchronous JavaScript and XML (异步JavaScript和XML)的首字母缩写,但现在所有 人都意识到它既不需要异步,也并非只能使用XML,所以现在Ajax代表的仅仅是“一种基于Web 的富客户界面,由大量非常巧妙的JavaScript所驱动”。Ajax是使用旧技术构建内容丰富且交互性强的用户界面的一种新方法。Google很好地检释了Ajax技术,例如在Gmail、Google Maps和Google Calendar这样的应用程序中就充分利用了这种技术。

MyBatis既可用于Web应用程序和富客户端应用程序,也可用于混合型应用程序。虽然表现层通常不会直接与持久化框架“交流”,但用户界面设计时的某些决定还是会影响你对持久层的需 求。举个例子,考虑一个Web应用程序,它需要处理一个包含5000条记录的大型列表。我们不可能需要同时显示出所有这5000条记录,而且如果我们不是立即需要使用它们,那么同时从数据 库中加载这5000条记录也不是什么好主意。一个更好的方案可能是一次只加载和显示10条记录。 这样的话,持久层就需要能够在返回数据的数量上允许一定的灵活性,甚至提供选择和获取我们 希望的10条记录的能力。这样就可以避免不必要的对象创建和数据获取,减少应用程序的网络访 问量和内存需求,进而提高应用程序的性能。MyBatis允许只查询某个特定范围内的数据,这样的 特性就可以帮助我们达到以上这些目的。

技术分享

业务逻辑层

  应用程序的业务逻辑层描述了应用程序所能提供的“粗粒度”的服务。正是这个原因,业 务逻辑层中的类有时也被称为服务类。从较高的层次来看,任何人都应该能看懂业务逻辑层中的类和方法进而明白系统到底要做什么。举个例子,在一个银行应用程序中,业务逻辑层可能就会包含名为TellerService的类,其中包括像openAccount ()、deposit () withdrawal () 和getBalance()这样的方法。这些都是非常大的功能,涉及复杂的数据库交互甚至可能是与其他系统的交互。这些方法太重了,不适合放在领域类中,否则代码很可能马上就会变得耦合、 并且通常会难以管理。解决方案就是将这些粗粒度的业务方法从与它们相关的业务对象模型中分离出来。这种业务逻辑类与对象模型类的分离有时也被称为“名词与动词的分离‘‘。

  纯面向对象论者可能会说,这样的设计不够面向对象,将业务方法直接放在相关的领域类中才更加面向对象。不论哪种方式更面向对象,能将关注点分离才是一个更好的设计选择。 其中的主要原因还是在于业务方法通常都非常复杂。它们通常都涉及不止一个类,处理不止 一种基础组件这些基础组件可能包括数据库、消息队列和其他系统。更重要的是,一个业务功能往往涉及许多领域类,那么该方法到底应该属于哪个类呢, 的确难以决定。也正是由于这些原因,粗粒度的业务功能最好还是实现为业务逻辑层中某个类的方法。

  不要害怕把那些粒度更细的业务逻辑放到相关的领域类中。业务逻辑层中那些粗粒度的服务 方法可以自由地调用内建在领域类中的细粒度的纯逻辑方法。

  在我们的分层架构中,业务逻辑层是持久层服务的消费者。它调用持久层的方法来获取数据和修改数据。业务逻辑层也是事务定界的最佳场所,因为其中定义的粗粒度业务功能可以供许多 不同的用户界面使用,甚至还可能被像Web服务这样的一些其他接口使用。

系列文章:

MyBatis知多少(1)

MyBatis知多少(2)

MyBatis知多少(3)

MyBatis知多少(4)MyBatis的优势

MyBatis知多少(5)业务对象模型

MyBatis知多少(6)表现层与业务逻辑层

标签:

原文地址:http://www.cnblogs.com/Coda/p/4643757.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!