一起谈.NET技术,Microsoft NLayerApp案例理论与实践 - 多层架构与应用系统设计原则

简介:   在对NLayerApp实际项目进行讨论之前,让我们首先学习一下(或者应该说重温一下)分层/多层架构与应用系统设计原则。很多朋友会认为这些都是老掉牙的内容,只要是软件从业人员,都会对这些内容非常熟悉。

  在对NLayerApp实际项目进行讨论之前,让我们首先学习一下(或者应该说重温一下)分层/多层架构与应用系统设计原则。很多朋友会认为这些都是老掉牙的内容,只要是软件从业人员,都会对这些内容非常熟悉。然而,果真如此吗?我在这里整理这部分内容,一方面是为介绍NLayerApp打下基础,而另一方面,则是希望借此机会将这些理论性的东西做个归纳,也希望读者朋友能够认真阅读,毕竟温故知新嘛。

  需要说明的是,从本章节开始,大多数理论性的东西都源自Microsoft Spain团队针对NLayerApp所编写的《Architecture Guide Book》,事实上这本Guideline的英文版至今也还没有完成,我会从中抽出部分章节做些翻译和归纳,有兴趣的朋友请直接上microsoftnalyerapp.codeplex.com站点上下载英文版阅读。

  Layers与Tiers

  对Layers与Tiers这两个单词进行区分是非常重要的。从中文翻译看,两者都是层的意思,因此我们往往会将这两个概念弄混。Layer一词更多的是表示对系统组件或功能的逻辑区分,它并没有包含将组件分布到不同的区域、不同的服务器上的意思。而Tier则是表示系统组件和功能在服务器、网络环境以及远程位置的物理部署。尽管这两个概念同时使用者非常相近的一些术语,比如展示、服务、业务和数据等,但我们必须了解它们之间的差别。下面这幅图表明了多层(N-Layer)逻辑架构与三层(3-Tier)物理结构之间的差异:

image

  需要注意的是,对于具有一定复杂度的应用程序而言,采用多层(N-Layer)逻辑架构的实现方式是非常必要的,这会降低系统的复杂度,并在设计、开发、测试、部署及维护等各个环节为应用系统带来高可用性、高延展性等正面效应。然而,并非所有的应用程序必须以三层(3-Tier)/多层(N-Tier)物理结构进行部署,我们可以将多个逻辑层部署在同一台机器上,也可以根据需求,将这些逻辑层部署在网络中的不同机器上。

  逻辑分层(Layer)的设计

  在讨论DDD的分层之前,先让我们看看传统的分层方式。就像上文所述,我们应该根据项目的实际需求,将组件/功能模块合理地划分到逻辑层中。同一层中的组件,应该是高内聚的,并具有相同的抽象层次。层与层之间应该低耦合。对于以分层设计的应用程序而言,最关键的问题就是如何处理层与层之间的依赖关系。考察传统的多层架构应用,处于某层的组件,只能对同层或下层的其它组件进行访问,这样做可以有效地降低层与层之间的依赖关系。通常会有两种分层设计:严格分层与灵活分层

  1. 严格分层迫使组件只能访问同层的其它组件,或者只能访问直接下层的其它组件,于是,第N层的组件只能访问第N或N-1层的组件,而第N-1层的组件只能访问第N-1或N-2层的组件,以此类推
  2. 灵活分层允许组件访问同层的其它组件,以及所有下层的其它组件,于是,第N层的组件可以访问第N或N-1、N-2…层的组件

  使用灵活分层的架构可以提高系统性能,因为这样的结构无需引入过多的请求/反馈的传递操作,因为一个层可以直接访问位于其下的任何层;而严格分层却降低了层与层之间的耦合性,对低层的修改不会对整个系统造成广泛的影响。根据Eric Evans在其《领域驱动设计-软件核心复杂性应对之道》一书中的描述,DDD的分层选用的是灵活分层模式。

  让我们再把讨论的粒度细化,来看看层中的组件与组件之间的关系。事实上,在很多复杂的应用中,位于同一层的组件与组件虽然具有相同的抽象层次,它们也不一定是高内聚的。因此,我们可以引入模块(Module)的概念,将同一层中高内聚的组件放在同一个模块中,于是,每个层又会由一个或多个高内聚的子系统(模块)所组成,如下UML组件图所示:

image

  使用分层架构,有如下几点好处:

  • 提高系统的可测试性
  • 对解决方案的维护和管理变得更加简单。层内高内聚、层间低耦合的结构,使得系统实现与分层组织方式变得非常灵活方便
  • 其它外部应用程序能够非常方便地使用不同的层所提供的特定功能
  • 当系统以层的方式进行组织时,分布式开发也变得非常简单易行
  • 在某些情况下,分层系统的物理部署方式能够给系统带来延展性,当然,应该有效地评估具体的实践方式,因为这种做法有可能损伤系统性能

  应用系统基本设计原则 - SOLID

  应用系统的设计应该遵循一些基本的设计原则,这能帮助你有效地创建一个低成本、高可用、高可扩展的应用程序。在这里,我们引入一个SOLID设计原则,SOLID由如下几点构成:

  • Single Responsibility Principle(单一职责原则)
  • Open Close Principle(开-闭原则)
  • Liskov Substitution Principle(里氏替换原则)
  • Interface Segregation Principle(接口分离原则)
  • Dependency Inversion Principle(依赖反转原则)

  下面简要介绍一下这几个原则。

  • 单一职责原则:每个类应该只有一个独一无二的职责,或者说每个类只能有一个主要功能,由此派生出一个结论:每个类应该尽可能少地依赖于其它类
  • 开-闭原则:每个类,应该对扩展进行开放,而对修改进行封闭,也就是支持扩展,而不是支持修改:类中的方法可以通过继承关系进行扩展,而不会改变类本身的代码
  • 里氏替换原则:子类可以被基类型(基类或者接口)替换。应用程序依赖抽象运行,其行为不会因为具体实现的改变而更改,应用程序应该依赖于抽象(基类或者接口),而不是具体实现。接下来将要讨论到的依赖注入(Dependency Injection)就与这条原则有关
  • 接口分离原则:接口的职责也应该是单一的,接口中应该包含哪些方法,需要进行严格的评估,如果其中某些方法的职责与接口的本身定义不相符合,则应该将其分离到其它接口中。类需要根据其调用者所需要的不同接口类型,来暴露不同的接口
  • 依赖反转原则:抽象不能依赖于具体,而具体则应该依赖于抽象。类之间的直接依赖应该用抽象来取代,这样做的一个优点是,我们可以实现自上而下的设计方式:在下层的具体实现还没有确定的情况下,只要能够在抽象层面将接口确定,就能够完成上层的设计与开发,这同样给可测试性带来便捷

  除了以上所述的SOLID原则之外,还有以下几个关键的设计原则可供参考:

  • 组件设计应该是高内聚的:相信大家都很熟悉这点了,就不多说了。例如:不要将数据访问逻辑写进领域模型的业务逻辑中,这与上述单一职责原则是密切相关的
  • 将Cross-Cutting的代码从特定于应用程序的逻辑中分离开来:Cross-Cutting的代码是一些面向横面的代码,比如安全、操作管理、日志以及测量/计量系统等。将这些代码与应用系统业务逻辑混在一起会增加系统的复杂性,给将来的扩展和维护造成很大的麻烦。这与面向方面编程(Aspect-Oriented Programming,AOP)有关
  • 关注点分离(Separation of Concerns,SoC):将应用系统分成多个子部分(子系统),各个部分之间的功能尽量不要重复,其目的就是为了减少交互点,以实现高内聚和低耦合
  • Don’t Repeat Yourself(DRY):一个特定的功能只能在某个特定的组件中实现一次,同样的功能不要在多个组件中重复多次
  • 避免YAGNI(You Ain’t Gonna Need It)效应:只考虑和设计必须的功能,避免过度设计

  好了,本讲就介绍到这里,估计对大多数接触过架构的软件朋友来说,本讲的部分内容都是废话。下一讲开始,我会花部分笔墨在DDD/DDDD的分层介绍上,虽然有可能还是废话,但这对我们理解NLayerApp的解决方案组织结构会有相当的帮助。

目录
相关文章
|
3天前
|
Kubernetes 持续交付 开发者
探索后端技术的未来:微服务架构与容器化部署的融合
在数字化时代的浪潮中,后端技术正经历着前所未有的变革。本文将深入探讨微服务架构和容器化部署如何共同推动后端技术的发展,提升应用的性能、可扩展性和可靠性。通过分析现代软件开发的需求,我们将揭示这两种技术如何互补,以及它们在未来后端开发中的潜力和挑战。
|
2天前
|
Kubernetes 监控 开发者
探索后端开发中的微服务架构实践
在现代软件开发领域,微服务架构作为一种灵活、可扩展的后端解决方案,正逐渐取代传统的单体式架构。本文将深入探讨微服务的设计理念、实施策略及其在企业级应用中的具体应用案例,旨在为读者提供一套系统的微服务实践指南。通过对比分析微服务与单体架构的性能差异,结合具体数据和案例研究,本文揭示了微服务在提高系统可维护性、可扩展性和敏捷性方面的优势。最后,文章讨论了微服务实施过程中可能遇到的挑战及解决策略,为后端开发者提供了宝贵的参考和启示。
|
3天前
|
Kubernetes 搜索推荐 开发者
探索后端开发的未来之路:微服务架构与容器化技术
随着云计算技术的不断成熟和普及,后端开发领域正经历着前所未有的变革。本文将深入探讨微服务架构和容器化技术如何重塑后端开发的面貌,提升系统的可扩展性、灵活性和可靠性。通过分析现代后端系统面临的挑战,我们将展示微服务和容器化如何提供解决方案,并预测这些技术如何塑造后端开发的未来发展。
19 3
|
3天前
|
消息中间件 监控 Kubernetes
后端开发中的微服务架构实践与挑战
在数字化时代的浪潮下,后端开发不断演化,微服务架构应运而生,成为解决复杂系统设计问题的一种新范式。本文将深入探讨微服务架构的核心概念、实施策略以及面临的主要技术挑战,同时结合具体案例分析其在实际开发中的应用效果和价值体现,旨在为后端开发人员提供一套系统的微服务实践指南和思考框架。
|
4天前
复用决策中,业务架构和技术之间有何关系
复用决策中,业务架构和技术之间有何关系
|
6天前
|
监控 负载均衡 安全
微服务架构下的服务发现与注册:技术深度解析
【7月更文挑战第20天】服务发现与注册是微服务架构中不可或缺的一部分,它确保了服务间的动态发现和通信。通过选择合适的实现工具和遵循最佳实践,可以构建出高效、可靠、可扩展的微服务系统。随着技术的不断进步,未来我们还将看到更多创新的服务发现与注册解决方案的出现。
|
9天前
|
监控 前端开发 JavaScript
构建高效实时应用:Python WebSocket在前后端分离架构中的实践
【7月更文挑战第18天】WebSocket助力实时Web应用,通过一次握手建立持久连接,解决HTTP实时性问题。Python中可用Flask-SocketIO创建WebSocket服务器,前端JavaScript使用Socket.IO库连接。确保安全可采用HTTPS、认证及跨域限制。示例代码展示如何实现双向实时通信。
32 4
|
5天前
|
运维 Kubernetes Cloud Native
云原生技术的未来演进:探索服务网格和无服务器架构的融合
随着企业数字化转型的不断深入,云原生技术已成为推动现代软件开发的关键力量。本文深入探讨了服务网格和无服务器架构这两大云原生技术趋势,分析了它们各自的优势以及未来可能的融合点。通过对比分析和案例研究,我们揭示了这两种技术如何互补并共同推进云原生生态系统的发展,同时指出了实践中面临的挑战和潜在的解决方案。 【7月更文挑战第22天】
|
8天前
|
监控 Cloud Native 安全
云原生架构在现代企业中的实践与挑战
本文深入探讨了云原生架构在现代企业中的应用及其面临的主要挑战。通过分析多个行业案例,文章揭示了云原生技术如何促进企业的数字化转型,提高系统的弹性、可扩展性和自动化水平。同时,指出了在实施过程中可能遇到的技术、安全和成本管理等问题,并提供了相应的解决策略,旨在为企业采用云原生架构提供实用的指导和建议。
|
3天前
|
缓存 监控 负载均衡
探索微服务架构中的API网关模式
在微服务架构的海洋中,API网关如同一座灯塔,指引着服务间的通信。本文将深入探讨API网关的设计哲学、关键功能以及在实际应用中的考量因素。通过对比分析,我们将揭示API网关如何在提高系统可维护性、增强安全性和优化性能方面发挥其不可或缺的作用。此外,文章还将提供实践指南,帮助读者在构建或改进微服务架构时,做出明智的API网关选择和部署决策。