⭐ 欢迎来到虫虫下载站！ | 📦 资源下载 📁 资源专辑 ℹ️ 关于我们
⭐ 虫虫下载站
📤 上传资源

📄 best_practice.htm

📁 buffalo学习资料
💻 HTM
字号:
🔍 
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<!-- saved from url=(0050)http://www.amowa.net/buffalo/zh/best_practice.html -->
<HTML><HEAD><TITLE>最佳实践</TITLE>
<META content="MSHTML 6.00.2900.2802" name=GENERATOR>
<META http-equiv=Content-Type content="text/html; charset=utf-8"><LINK 
href="best_practice.files/stylesheet.css" type=text/css rel=stylesheet></HEAD>
<BODY>
<DIV class=header id=header>
<H1>最佳实践</H1>
<H2>Michael Chen</H2>
<H3>2005/12/24</H3></DIV>
<DIV class=toc id=toc>
<UL>
  <LI><A 
  href="http://www.amowa.net/buffalo/zh/best_practice.html#toc1">使用DTO封装复杂的级联领域对象</A> 

  <LI><A 
  href="http://www.amowa.net/buffalo/zh/best_practice.html#toc2">仔细构造Buffalo服务接口</A> 

  <LI><A 
  href="http://www.amowa.net/buffalo/zh/best_practice.html#toc3">采用浏览器前进/后退新特性</A> 

  <LI><A 
  href="http://www.amowa.net/buffalo/zh/best_practice.html#toc4">设计更具交互性的用户界面</A> 

  <LI><A 
  href="http://www.amowa.net/buffalo/zh/best_practice.html#toc5">在小型应用中，考虑OPOA</A> 

  <LI><A 
  href="http://www.amowa.net/buffalo/zh/best_practice.html#toc6">大型应用中，善用OPOA</A> 
  </LI></UL></DIV>
<DIV class=body id=body>
<P>下面的实践代表了amowa概念的实现以及buffalo的实际应用中产生的问题和应对策略。这些策略不仅代表了buffalo的应用方式，而且代表了Ajax/Amowa应用应当遵循的一些实践原则。适当采纳这些原则，能够让你的应用更加合理，不至于滥用Ajax/Amowa. 
从根本上说，buffalo是一个为了改善用户体验而产生的框架，因此以下的实践绝大多数情况都从这个方面进行考虑。 </P><A name=toc1></A>
<H2>使用DTO封装复杂的级联领域对象</H2>
<P>ORM工具的引入为我们的JavaEE开发提供了便利。在传统的开发中，我们可以定义良好的领域模型，然后让这个模型在JavaEE的三个层次之间传递，从而达到概念一致性和简化编程的目的。这种编程模型哪怕是在集群的系统中，都没什么问题——因为是在同一个JVM内部，对象内部状态可以保持。然而，在buffalo应用中，这种实践却最好不要进行。因为buffalo客户端与应用的服务层之间的交互属于远程调用，这其中首先要考虑的问题就是带宽问题。 
</P>
<P>例如，一个userService.listUser，返回一个用户列表，而用户往往关联着其它的信息，如地址信息，部门信息，项目信息。按照传统的编程方式，用户JSP可以自由的引用user的各种属性和方法，不用担心多余的属性会如何，因为这一切的操作都在同一个JVM内部，真正展现在页面的数据只是请求的那些数据。而按照buffalo的编程方式，在不进行任何数据处理的情况下，调用userService.listUser会将整个user对象的结构数据全部下载回来，包括在ORM中的定义的各种一对多，多对多的各种关系的引用数据。在绝大多数情况下，用于表示的数据不需要那么多，因此这浪费了带宽。 
</P>
<P>因此在做系统优化和设计的时候，对于复杂级联的领域对象输出，考虑用DTO进行封装，仅仅将需要显示的数据包含进来。 </P><A name=toc2></A>
<H2>仔细构造Buffalo服务接口</H2>
<P>真正为远程服务构造接口，要求能够对客户端发起的buffalo请求，一次性的给予全部回复，而不是客户端需要再次调用其他的方法。这个要求可能导致的结果是服务接口提供的方法非常多，或者方法需要的参数比较多。这样做能够为客户端提供更加便利的调用选择，改善编码体验。 
</P><A name=toc3></A>
<H2>采用浏览器前进/后退新特性</H2>
<P>许多用户（包括我在内），当一个web应用不能利用浏览器的前进后退来切换视图的时候，都会感到迷惑。buffalo考虑到了这一点，因此在1.2版本中引入了这一特性。请善用这一特性，改善用户体验。 
</P><A name=toc4></A>
<H2>设计更具交互性的用户界面</H2>
<P>这是一个通用的要求。按钮，链接，点击的时候要具备操作感觉，例如，鼠标移上有标识，鼠标按下的时候有感觉。在传统应用中，这些操作往往代表了页面切换，用户知道他的动作有了反应；但新ajax/amowa应用没有了页面切换，按钮如果不具备交互感觉，用户会感觉操作很难受。 
</P><A name=toc5></A>
<H2>在小型应用中，考虑OPOA</H2>
<P><A href="http://michael.nona.name/archives/117">OPOA</A> 
定义了Web应用的形态。小型应用一般页面较少，要求交互性强。典型的有邮件应用，某些系统的监控程序，对于这些应用，完全可以考虑使用OPOA. </P><A 
name=toc6></A>
<H2>大型应用中，善用OPOA</H2>
<P>由于浏览器的能力限制，大型应用在采用OPOA的时候，往往操作一段时间后，出现内存暴涨，或者CPU占用较大的情况。对于这种情况，如果要应用OPOA，需要对应用进行拆分，按照模块或者子系统，将系统拆分为若干个一个页面能够承担的分量。每个页面可以相同，只是在切换子系统的时候，是<B>真正的切换页面</B>，而不是switchView. 
这样浏览器在切换页面后会释放内存，从而达到释放资源的目的。这其中，应用拆分的粒度需要开发者进行控制，拆分原则除了应用的逻辑结构外，还需要考虑客户机器的处理能力。 
</P></DIV><!-- html code generated by txt2tags 2.3 (http://txt2tags.sf.net) --><!-- cmdline: txt2tags best_practice.t2t --></BODY></HTML>

⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -