围绕HMVC和AJAX设计应用程序[Kohana 3.2]

时间:2011-12-14 18:12:52

标签: ajax kohana hmvc

我目前正在设计一个具有几个不同页面的应用程序,每个页面都有通过AJAX更新的组件。布局类似于新的Twitter设计,其中“Home”,“Discover”和“Connect”是单独的页面,但在页面内进行交互(例如单击“Followers”或“Follow”)使用AJAX。

由于设计需要初始页面加载多个组件(在Twitter的上下文中:推文,关注者,以下),每个都可以通过AJAX单独更新,我认为最好有一个默认控制器对于提供页面和其他控制器的操作,而不是提供整页,严格处理查询数据库和返回JSON对象。这样,在初始页面加载时,可以使用几个HMVC请求来收集每个组件的数据,并且还可以进行AJAX调用以单独更新每个组件。

我的想法是拥有一个处理服务页面的Controller_Default。在Twitter的上下文中,Controller_Default将包含:

action_home()
action_connect()
action_discover()

然后我会让其他控制器不处理整页的服务,而是处理页面的组件。例如,在Twitter Controller_Tweet的上下文中可能有:

action_get()

返回包含特定用户推文的JSON对象。然后,Action_home()可以发出几个HMVC请求来获取页面的几个不同组件的数据(即请求'tweet / get','followers / get','follow / get')。但是,在页面上,可以对功能特定的控制器(即“tweet / get”)进行AJAX调用以更新内容。

我的问题:这是一个好设计吗?通过默认控制器提供页面是否有意义,页面组件通过其他功能特定的控制器提供(以JSON格式)?

如果对此问题有任何疑惑,请随时要求澄清!

1 个答案:

答案 0 :(得分:0)

HMVC模式的优势之一是采用这种类型的分层应用程序并不会将您锁定在以后可能难以更改的工作流程中。

根据您上面所说的,作为向客户提供内容的一种方式,这将是完全可以接受的;默认控制器包装子请求,这避免了来自客户端的多个AJAX调用以实现相同的目标。

我可能提出两点建议:

  1. 确保您的Twitter后端请求在库中被抽象出来并进行管理,以使应用程序更干净,更易于维护。
  2. 考虑默认控制器是否仅对每个请求进行绝对必要的调用。使用缓存以避免在每个请求上提取不经常更改的数据(例如,关注者可能每30秒更新一次)。这当然完全取决于您的应用程序要求,但如果您负载过重,您可以快速找到您的Twitter API请求限制。
  3. 最后一个观察结果:如果您确实发现服务器负载过高且Twitter API请求需要很长时间才能返回,请考虑配置另一台服务器并安装应用程序的副本。然后,您可以将来自默认网关应用程序的子请求“指向”第二个应用程序服务器,如果两个服务器通过高速链接连接,这有助于缩短响应时间。