烧瓶 MVT。重构到服务层
在这篇简短的文章中,我想展示我们如何在模型视图模板方法中使用服务层模式来改进关注点分离。
模型视图模板
MVT 是一种应用程序构建模式,通常用于像 Flask(还有 Django)这样的框架。
它由三个独立的组件组成:
- 负责领域逻辑和持久性的模型层。
2.查看对处理http请求的关注。它是定义应用程序 API 的地方。视图通过与模型交互和执行对外部服务的请求来编排应用程序逻辑。
3.模板是处理用户界面部分的表示层(例如html模板)。
[
](https://res.cloudinary.com/practicaldev/image/fetch/s--UEubh3z0--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://cdn .hashnode.com/res/hashnode/image/upload/v1637924048990/_vyXOsAHI.png)
MVT 方法通常会导致以下代码异味:
-
将处理 http 请求的资源(例如对查询字符串参数、cookie、标头等进行操作)与应用程序逻辑编排(框架和业务需求之间的强耦合)混合在一起。
-
复杂的测试设置(总是需要一个http请求来测试应用程序逻辑)。
-
混合领域逻辑和持久性的责任(基础设施问题)
将您的框架推到应用程序逻辑之外
可以缓解上述三种气味中的前两种的解决方案是引入服务层(它可以是类,也可以是独立功能,具体取决于具体情况)。它可以将应用程序逻辑与我们使用的框架解耦(应用程序功能/用例与框架代码无关)。 View 现在负责处理请求和执行服务层方法/功能,而应用程序逻辑现在只是服务层的关注点。它允许我们首先专注于应用程序核心,然后实现能够进入它的 API。由于分离,API 不需要是支持渲染模板的 API,它可以是 CLI(命令行接口)、REST API、GraphQL API、RPC 等。关于 API(和框架)的决定可以推迟,但是我们仍然可以开发我们的应用程序功能。
API 和应用程序逻辑分离也可以改进我们的测试。我们现在可以编写应用程序核心的测试,广泛覆盖逻辑路径,同时只覆盖 API 部分的快乐路径。
[
](https://res.cloudinary.com/practicaldev/image/fetch/s--kjyslM8V--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://cdn .hashnode.com/res/hashnode/image/upload/v1637918478947/8Uk5e6ZWI.png)
结论
这个解决方案当然不是灵丹妙药。当我们的视图端点很大而不是微不足道时,我们应该考虑它,并且编写干净、可读的代码具有挑战性。
更多推荐

所有评论(0)