促销活动
CodeGym University
学习
课程
任务
调查和小测验
游戏
帮助
提醒时间表
社区
用户
论坛
聊天
文章
成功故事
活动
评论
订阅服务
浅色主题
课程
评论
关于我们
开始
开始学习
立即开始学习
目标地图
课程
级别 14
客户端-服务器架构
模块 3
第 14 级,
课程 0
1.1 应用架构 本课程专为初学者设计,因为您不会长时间设计严肃应用程序的架构。但别担心,好的架构是例外而不是规则。在构建应用程序之前选择正确的应用程序架构是非常困难的。 大型服务器应用程序的流行架构示例: 分层架构(Layered Architecture)。 分层架构。 面向服务的体系结构 (SOA)。 微服务架构(Microservice Architecture)。 他们每个人都有其优点和缺点。但是研究它们不会给你任何东西。架构是对“如何组织系统内数千个对象的交互”这
三层架构
模块 3
第 14 级,
课程 1
三层架构简介 三层架构是互联网上最常见的交互架构。当两层服务器部分被分为逻辑层和数据层两部分时,它就出现了。 它看起来像这样: 客户端层是负责用户交互的“分布式应用程序”的一部分。该层不应包含业务逻辑,也不应存储关键数据。此外,它不应直接与数据库层交互,而只能通过业务逻辑层进行交互。 但是,这里仍然有一些逻辑。首先,这是通过界面与用户交互,验证他输入的数据,使用本地文件。这还包括使用服务器时与用户授权和数据加密相关的所有内容。 其次,是简单的业务逻辑。例如,如果一个在线商店发
MVC方法
模块 3
第 14 级,
课程 2
MVC架构介绍 每个程序员都知道的最流行的应用程序架构是MVC。MVC 代表模型-视图-控制器。 这与其说是应用程序的架构,不如说是应用程序组件的架构,但我们稍后会回到这个细微差别。什么是 MVC? MVC 是一种将应用程序数据和控制逻辑分离为三个独立组件(模型、视图和控制器)的方案,以便每个组件都可以独立修改。 模型(Model)通过改变其状态来提供数据并响应控制器命令。 视图负责向用户显示模型数据以响应模型更改。 控制器(Controller)解释用户的动作,通知模型需要
良好软件架构的标准
模块 3
第 14 级,
课程 3
效率 有经验的程序员可以很容易地分辨出架构的好坏,但如果被要求用几句话来描述它,他们不太可能做到。好的架构没有单一的标准,也没有单一的定义。 然而,如果你仔细想想,你可以写出一些好的架构应该满足的标准。一个好的架构首先是一个逻辑架构,它可以让程序的开发和维护过程更简单、更高效。 当程序具有良好的体系结构时,总是很容易理解它是如何工作的以及在何处编写代码。一个结构良好的程序更容易更改、测试、调试和开发。聪明人制定了以下优秀架构的标准: 效率; 灵活性; 可扩展性; 可扩展性;
不良软件架构的标准
模块 3
第 14 级,
课程 4
不良设计的标准 生活很简单:通常,要聪明,你只需要不做傻事。这也适用于软件开发:在大多数情况下,要想把一件事做好,你只需要不把它做得不好。 大多数程序员都有过设计糟糕的系统部分的经验。但更可悲的是,你们中的大多数人都会有悲伤的经历,意识到自己是这样一个系统的作者。我们想要最好的,但结果一如既往。 大多数开发人员并不渴望糟糕的架构,对于许多系统来说,他们开始说它的架构很糟糕。为什么会这样?架构设计是从一开始就不好,还是随着时间的推移变得不好? 这个问题的根源是缺乏“坏”设计的定
模块化软件架构
模块 3
第 14 级,
课程 5
6.1 分解 尽管标准多种多样,但大型系统开发的主要任务是降低系统的复杂性。为了降低复杂性,除了分成几部分之外什么也没有发明。 有时,为了简单起见,这被称为“分而治之”原则,但是,从软件架构师的角度来看,我们谈论的是层次分解。 一个复杂的系统必须由少量较简单的子系统构建而成,每个子系统又由较小的部分构建,依此类推,直到最小的部分足够简单,可以直接理解和创建。 好消息是这个解决方案不仅是唯一已知的,而且是通用的。除了降低复杂性之外,它还通过复制关键部分同时提供系统灵活性、良好的
正确的软件分解
模块 3
第 14 级,
课程 6
层次分解 您永远不应该立即开始为您的应用程序编写类。首先需要对其进行设计。设计应该以深思熟虑的架构结束。要获得此架构,您需要始终如一地分解系统。 分解必须分层进行——首先,系统被分成大的功能模块/子系统,以最一般的形式描述其操作。然后对生成的模块进行更详细的分析,并将其划分为子模块或对象。 在选择对象之前,将系统分成基本的语义块,至少在心理上是这样。在小型应用程序中,这通常很容易做到:几个级别的层次结构就足够了,因为系统首先分为子系统/包,而包又分为类。 这个想法并不像看起来
如何松散软件模块之间的耦合
模块 3
第 14 级,
课程 7
8.1 分解就是一切 为了清楚起见,一张来自一篇好文章“面向对象系统的解耦”的图片说明了将要讨论的要点。 您还认为设计应用程序架构很容易吗? 8.2 接口,实现隐藏 降低系统耦合度的主要原则是OOP的原则以及其背后的封装+抽象+多态的原则。 因此: 模块应该是彼此的“黑盒子”(封装)。这意味着一个模块不应该“爬升”到另一个模块并且不知道它的内部结构。一个子系统中的对象不应该直接访问另一个子系统中的对象。 模块/子系统应该仅通过接口(即不依赖于实现细节的抽象)相互交互。因此,每
依赖倒置
模块 3
第 14 级,
课程 8
9.1 依赖倒置 请记住,我们曾经说过,在服务器应用程序中,您不能只通过创建流new Thread().start()?只有容器应该创建线程。我们现在将进一步发展这个想法。 所有对象也应该只由容器创建。当然,我们不是在谈论所有对象,而是在谈论所谓的业务对象。它们通常也被称为垃圾箱。这种方法的支柱源于 SOLID 的第五条原则,该原则要求摆脱类并转向接口: 顶级模块不应该依赖于低级模块。那些和其他人都应该依赖于抽象。 抽象不应依赖于细节。实现必须依赖于抽象。 模块不应该包含对特
链接软件模块的替代方法
模块 3
第 14 级,
课程 9
用消息传递代替直接依赖 有时一个模块只需要通知其他人它发生了一些事件/变化,而这些信息以后发生什么并不重要。 在这种情况下,模块之间根本不需要“相互了解”,即包含直接链接并直接交互,但只需交换消息(messages)或事件(events)就足够了。 有时似乎通过消息传递的模块通信比直接依赖要弱得多。事实上,因为没有调用方法,所以没有关于类的信息。但这只不过是一种错觉。 逻辑开始与消息类型、它们的参数和传输的数据相关联,而不是方法名称。这些模块的连接性被抹黑了。 它曾经是这样的
Please enable JavaScript to continue using this application.