三层与n层之间的差异

我刚看到以下句子:

随着行业从三层模型转向n层模型,对象关系阻抗不匹配变得更加普遍.

但我找不到三层和三层之间差异的简明解释.我知道三层是什么,我认为n层只增加了一层或多层.我只是不确定这些额外的层是什么.如果有人有简短的解释或只是一个很好的链接,那将非常感激.

在开发中,我们将层级理解为" 责任层次 "抽象.

这种责任水平将概念组合在一起,以提供对现实的连贯语义观,或至少与现实相似的东西.

在这种意义上,所谓的3层模型或n层模型只是这些概念的不同实现.

层级的一个很好的例子是遵循神经模型,在这个模型中,责任被认真地传达给适当的人.例如,一个共同的业务有商业,营销,系统,开发和测试部门(例如),它们代表业务层.这样,责任是明确的,开发提供产品,测试测试它,营销推广它和商业销售它,所有这些,而系统保持基础设施运行(只是一个例子).

这个比喻首先与3层模型接洽,其中确定了三层.通常这个层是数据库抽象层,它负责数据库的通信和抽象,业务规则层,它包含描述业务流程的规则和用户界面层,用户界面层抽象用户与系统的交互.

这样,我们就拥有了每个层的职责角色,因此,如果用户需要与系统进行交互,他将与一个层进行通信,而不是跨越漏洞系统.

N层通过使用更多层来满足特定需求来代表前一概念的演变.通常用户界面层和数据库抽象层保持不变,因为它们的角色非常清晰,而业务规则层进一步细化.

为此,我们始终考虑问题的特征以及我们现在和将来想要提供的功能.例如,如果一个应用程序需要与智能客户端一起工作或者预见到它可以与智能客户端一起工作,那么业务层通常分为代理层和后端层,第一层将呼叫路由到它们应该去的地方.

最后,重要的是在不同层之间抽象责任的概念,并从同一个地方的语义视图集中所有相关操作.

另外,n层架构允许在开发人员之间分配这些"责任".这样,给定的团队可以对数据库抽象层负责,而其他团队在代理层上工作,另一个团队在图形抽象层上工作.当团队成员需要访问数据库时,他会查找DAL文档并使用其中一个提供的工具或要求DAL团队提供他需要的功能,这样他就不会直接解决数据库问题,而是通过人员更了解数据库本身的设计和复杂性.

如果我们看到层层叠叠的蛋糕; 每一层都有它自己的成分,做它自己的东西.每个应用程序的层仅与其上方或下方的层相互作用.

3层意味着蛋糕有3层.通常它是底部的数据,然后是应用程序逻辑层(PHP/ruby​​/etc),然后是顶部的表示层(html)

拥有n层架构意味着您可以设计多层图层.您拥有的图层数量取决于您决定如何制作图层.

对于大型或Web应用程序来说似乎更有意义.

我通常最终得到一个5层的应用程序.每个层只能与其上方或下方的层进行交互.这可以为您的应用程序提供出色的可扩展性和标准化.

客户层

网页浏览器

演示层

渲染HTML - Coldfusion/Flash/Ruby/PHP等.

业务逻辑层

根据需要运行流程和计算 - Coldfusion/Flash/Ruby/PHP等.

数据集成层

(来自我的开发语言,存储过程等的查询)

数据层

(数据库 - MySQL等)

引用似乎来自此代码项目页面.它似乎也很好地解释了n层,包括Web服务,javascript,工作流等等.3层模型不一定包含所有东西.

n层意味着n是任意数字 - 当n = 3时,它与n层相同.

3层的通常定义是表示,逻辑和数据(以任何顺序),是的,SOA可能会混淆新手,因为有时它位于数据层,有时是逻辑层,有时是逻辑层和数据层.

整个主题是......主观的.如果你需要一些层,那么称之为n层 - 如果你知道n = 7,那么称之为7层或n层.