【问题标题】:Verbose Listing of All Application Layers/Tiers?所有应用层/层的详细列表?
【发布时间】:2011-01-29 15:54:27
【问题描述】:

我现在查看了一些站点,但我仍在努力寻找一个应用程序中所有可能的层/层的完整列表。

从大学回来(1999 年)我记得以下几点:

  • 表示层(视图)
  • 应用层(控制器)
  • 业务逻辑层(API/规则)
  • 持久层(数据库/对象持久性/模型)

我并不是提倡全部使用它们...尤其是当您考虑到太多的层/层可能会导致复杂性增加...我只是想知道完整的列表可能是什么样子...

根据几篇博客,我找到了几个不同的答案......根据blog,Javascript 和客户端技术似乎在添加更多客户端层时泄漏了,客户端层甚至可能包括

  • 行为层(Javascript、Flash)
  • 表示层(CSS/图像)注意:我虽然整个客户端层都是表示层
  • 结构层(XHTML、HTML)

我只是想对所有可能的层有一个抽象的概念,(尽管有些人称它们为不同的东西)

【问题讨论】:

  • 谷歌“N 层架构”。看看你能不能通过这种方式找到更多。

标签: architecture web-applications layer tiers


【解决方案1】:

我会在您的列表中添加一个“集成层”。该层包含外部系统(电子邮件服务器、Web 服务等)的包装类。这些类实现了业务逻辑层提供的接口(与“持久层”应该采用的方式相同)。

【讨论】:

    【解决方案2】:

    如果您在谈论抽象,那么您可能找不到明确的层或层列表;此外,您遇到的任何列表都将取决于上下文。

    层(或层)可以是逻辑的或物理的;表示层通常与业务逻辑在物理上是分开的——但我想说你上面的应用层和业务层更像是一个逻辑的东西(?)。

    另一个关键方面是你的观点。根据您采用的视图,您会看到不同的层:http://www.opengroup.org/architecture/togaf8-doc/arch/chap31.html#tag_32

    最后,沿着这些思路,解决方案的复杂性和/或性质也会对此产生影响 - 如果您广泛使用服务,那么您将拥有服务视图 - 或服务层。您考虑的层将受到您是考虑单个系统/组件还是更广泛的解决方案的影响。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2013-08-30
      • 1970-01-01
      • 2020-03-25
      相关资源
      最近更新 更多