文档建议反馈控制台
首页
学习
活动
专区
工具
TVP
最新优惠活动
文章/答案/技术大牛
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

如果我遵循的是Clean Architecture，我应该把检查外键是否存在的逻辑放在哪一层？

根据Clean Architecture的原则，检查外键是否存在的逻辑应该放在数据访问层（Data Access Layer）或者领域层（Domain Layer）中。

在Clean Architecture中，数据访问层负责与数据库或其他数据存储系统进行交互，包括数据的读取、写入和更新等操作。在这一层中，可以通过查询数据库或其他数据存储系统来检查外键是否存在，以确保数据的完整性和一致性。

另一方面，领域层是应用程序的核心，包含了业务逻辑和规则。在这一层中，也可以进行外键的存在性检查，以确保业务操作的有效性和正确性。

具体来说，可以根据实际情况选择将检查外键是否存在的逻辑放在数据访问层或领域层中。如果检查外键是否存在是一项与数据存储紧密相关的操作，可以将其放在数据访问层；如果检查外键是否存在是一项与业务逻辑紧密相关的操作，可以将其放在领域层。

以下是腾讯云相关产品和产品介绍链接地址，供参考：

  1. 数据库：腾讯云数据库（https://cloud.tencent.com/product/cdb）
  2. 服务器运维：腾讯云云服务器（https://cloud.tencent.com/product/cvm）
  3. 云原生：腾讯云容器服务（https://cloud.tencent.com/product/tke）
  4. 网络通信：腾讯云私有网络（https://cloud.tencent.com/product/vpc）
  5. 网络安全：腾讯云安全产品（https://cloud.tencent.com/solution/security）
  6. 音视频：腾讯云音视频服务（https://cloud.tencent.com/product/tcvs）
  7. 多媒体处理：腾讯云媒体处理（https://cloud.tencent.com/product/mps）
  8. 人工智能：腾讯云人工智能（https://cloud.tencent.com/product/ai）
  9. 物联网：腾讯云物联网开发平台（https://cloud.tencent.com/product/iotexplorer）
  10. 移动开发：腾讯云移动开发平台（https://cloud.tencent.com/product/mpp）
  11. 存储：腾讯云对象存储（https://cloud.tencent.com/product/cos）
  12. 区块链：腾讯云区块链服务（https://cloud.tencent.com/product/bcs）
  13. 元宇宙：腾讯云元宇宙解决方案（https://cloud.tencent.com/solution/metaverse）
相关搜索:js 判断文档高度用js检测是否联网js排序不分大小写js怎么判断是汉字js中判断汉字个数js 爬虫模拟登陆js事件机制是什么js将小数四舍五入js对象存数据类型js数字转成千分位
相关搜索:
页面内容是否对你有帮助？
有帮助
没帮助

相关·内容

Easy Clean architecture on Android

本文的目标是分享我使用clean Architecture构建项目时所收获的经验，希望能够为你的项目改进带来灵感。...无论什么理由这种创造“上帝类”的做法都应该尽量避免，我们不应该把重点放在编写那些大而全的类，而是投入精力去编写那些易于维护和测试的低耦合类，如果可以的话，最好不要让业务逻辑进入纯净的Android世界，...另外值得一提的是architecture是面向软件设计的，它不应该做语言差异，而本文将主要讲述如何结合Clean Architecture构建你的Android应用程序。...业务逻辑层 最重要的是业务逻辑层，我们在这里解决所有业务逻辑，这一层不应该包含Android代码，应该能够在没有Android环境的情况下测试它，也就是说我们的业务逻辑能够被独立测试，开发和维护，这就是...Apply on Android 按照上面提到的分层原则，我把项目分为了三层，也就是说它有三个Android module，如下图所示： Clean architecture modules 在Domain

55230

Golang 简洁架构实战

比如： 对于功能实现我是通过 function 的参数传递还是通过结构体的变量传递？ 使用一个数据库的全局变量引用传递是否安全？是否存在过度耦合？...所以我觉得是时候自我改变一下。 The Clean Architecture 在简洁架构里面对我们的项目提出了几点要求： 独立于框架。该架构不依赖于某些功能丰富的软件库的存在。...如果使用 ORM，那么这里放入的ORM操作相关的代码；如果使用微服务，那么这里放的是其他服务请求的代码； service 这里是业务逻辑层，所有的业务过程处理代码都应该放在这里。...这一层会决定是请求 repo 层的什么代码，是操作数据库还是调用其他服务；所有的业务数据计算也应该放在这里；这里接受的入参应该是controller传入的。...func main() { server := InitServer() server.Start() } 测试 在上面我们定义好了每一层应该做什么，那么对于每一层我们应该都是可单独测试的，即使另外一层不存在

1.1K10

【译】Android开发中的MVP架构

如果一个类需要花费时间从其他类中通过Get()和Set()检索数据（也就是说，需要深入业务并且告诉它们如何去做），所以是否应该把这些功能函数更好的组织到其它类而不是上帝类中。...其实最大的问题莫过于在Activity中同时存在业务逻辑和UI逻辑。这会增加测试和维护的成本。 ? Activity是上帝 这是为什么需要清晰架构的原因之一。...Uncle Bob的“The Clean Architecture”描述了依赖的规则是什么。 同心圆将软件划分为不同的区域，一般的，随着层级的深入，软件的等级也就越高。...外圆是实现机制，内圆是核心策略。...那么，哪一个才是最好的呢？哪一个比其他的更优秀呢？我能只选择一个吗？ 答案是，NO。 这些模式的动机都是一样的。那就是如何避免复杂混乱的代码，让执行单元测试变得容易，创造高质量应用程序。就这样。

48820

浅析整洁架构之道(三) 明析分层原则

架构的分层概述 ? 在我们开始之前，我们再次回到The Clean Architecture的这个概述图上来。...如果基于这个场景来分析，那交易本身相关的业务逻辑，就应该放在Entities层，如转帐，存钱，取钱等，这些属于业务核心。你应该把这些业务的逻辑放在Entities这一层来实现。...大多数情况下，这是一个系统需求，因为本身大多数业务不存在这个行为，这是一个典型的因为系统带来的行为的需求。因此，这一个逻辑大多数情况下你应该放在Use Cases层。...但如果是类似银行等系统，记录用户行为，如张三在10月1日09:10分存了1万元钱这种并非系统带来的，而是业务本身就一定需要记录的，那这个需求应该放在Entities层来实现。...所以，分析具体的需求是业务行为还是系统行为是非常重要的一件事。它决定的这一块的逻辑放哪一层来实现。

81610

千万级规模遗留系统债务度量改造实践

通过 DSL 的方式可以定义一些类名、包名，你要把这些包名传到 function 里面，我再来计算你传过来的这些包是否符合 Clean Architecture 的定义。...架构该有的样子 由于信息安全，我只能把 Clean Architecture 官网上的图截出来一起探讨。我认为不管服务面向云原生还是面向于公司内部平台都会依赖基础设施层。...比如今天我们要依赖阿里云，阿里云有整套的基础设施，明天我们要迁移到 AWS 上，理论上我们只需要把最外层的基础设施进行一层适配就可以了，架构设计中需要的是消息中间件，业务代码中不应该感知到具体是 Kafka...这需要团队的强执行力，比如在检视中一定要看静态代码检查的规范或 Bad Smell 是怎么改的才可以。Clean Code 改得再好，我也不认为这个代码就是好代码。什么样的代码是好代码？...通过四个层的定义，只要你把它指定到你的某一个包名下，就会自动地去帮你去 check 包之间的依赖关系是不是符合 Clean Architecture 的定义。

21420

【总结】1773- 前端简洁架构

这一点在判断模块应该属于哪一层的时候会很重要。 依赖规则（Dependency Rule） 三层架构有一个依赖规则：只有外层可以依赖内层。这意味着 领域必须是独立的。 应用层可以依赖领域。...你可以在源代码中找到其他的用例。 首先，我们将定义所拥有所有这些实体、用例和广义上的功能，然后决定它们应该属于哪一层。 设计领域 一个应用程序中最重要的是领域，它包含了应用程序的主要实体和数据转换。...以这种方式设计实体类型的好处是，我们已经可以检查它们的关系图是否与现实相符。...分支业务逻辑 最重要的问题是我们对于主题领域的了解不足。想象一家商店有产品、折扣产品和报废产品。我们如何正确描述这些实体？ 是否应该有一个“基础”实体进行扩展？这个实体应该如何扩展？...是否需要额外的字段？这些实体是否应该互斥？如果简单的实体变成了其他实体，用例应该如何行为？是否应该立即减少重复？ 可能会有太多的问题和太多的答案，因为团队和利益相关者还不知道系统应该如何实际运行。

20230

什么是前端简洁架构

这一点在判断模块应该属于哪一层的时候会很重要。 依赖规则（Dependency Rule） 三层架构有一个依赖规则：只有外层可以依赖内层。这意味着 领域必须是独立的。 应用层可以依赖领域。...你可以在源代码中找到其他的用例。 首先，我们将定义所拥有所有这些实体、用例和广义上的功能，然后决定它们应该属于哪一层。 设计领域 一个应用程序中最重要的是领域，它包含了应用程序的主要实体和数据转换。...以这种方式设计实体类型的好处是，我们已经可以检查它们的关系图是否与现实相符。...分支业务逻辑 最重要的问题是我们对于主题领域的了解不足。想象一家商店有产品、折扣产品和报废产品。我们如何正确描述这些实体？ 是否应该有一个“基础”实体进行扩展？这个实体应该如何扩展？...是否需要额外的字段？这些实体是否应该互斥？如果简单的实体变成了其他实体，用例应该如何行为？是否应该立即减少重复？ 可能会有太多的问题和太多的答案，因为团队和利益相关者还不知道系统应该如何实际运行。

27820

前端代码复用学习笔记:整洁架构与清晰架构

，稍微大点的团队都有自己的业务组件库，但是我去过的很多团队都有落地难的问题，其中有些是技术层面的，但是更多的是出现在跨职责协作上，其中，我认为影响最大的是 UI 设计师和前端开发之间的协作关系UI 组件资产...可能在代码迁移合并升级的时候，我们能做的可能只有重构。我们可能会想到使用 Web Components 或者是微服务，但是带来的可能会是，更多的浏览器限定，要看更多的框架文档去遵循更多的规范。...我们要去用我们不变的 JS 代码去适配更多框架的 VM。Clean Architecture 是由 Robert C....我们只需要变动接口适配器层和框架与驱动层，业务逻辑层可以继续复用如图所示 Clean Architecture 一共分为四个环，四个层级。...其类似于 SOLID 中的依赖倒置原则：高层模块不应该依赖低层模块，两者都应该依赖其抽象抽象不应该依赖细节，细节应该依赖抽象与此同时，四个环都存在各自核心的概念：实体 Entities （又称领域对象或业务对象

72120

一篇文章教你分辨领域服务与应用服务

作者 | 张逸 判断什么时候应该定义领域服务，什么时候应该定义应用服务，一个根本的判断依据是看需要封装的职责是否与领域相关。...Clean Architecture 如果参考Robert Martin的Clean Architecture以及Cockburn的六边形架构，我们可以将分层架构的应用层对应到Clean Architecture...验证 如果是验证外部客户传递过来的消息，例如对RESTful服务的Request请求的验证，则该验证功能属于横切关注点，对它的调用就应该放在应用服务边界。...如果验证逻辑属于领域范畴，例如验证订单有效性，这种验证体现的是一种业务规则，则验证逻辑的实现就应该放在领域层，对验证逻辑的调用也应该属于领域对象，包括领域服务。...我个人倾向于将调用通知服务的逻辑放在应用服务中，除非通知服务自身可能与主业务强相关。

4K80

领域驱动设计中的架构要素

因为我倾向于将Uncle Bob的Clean Architecture与DDD的分层架构整合起来，如下图所示： ? 在这个架构图中，基础设施层处于最外部，然后是应用层，最核心的是领域层。...基础设施中的模块，我都称之为gateway。根据依赖方向，如果是被调用的方向，即由外至内的调用方向，就是北向，称之为北向网关。...为了解除应用层或领域层与它的耦合，南向网关往往需要提供接口。这就说明，基础设施层的南向网关都是具体实现，内层对南向网关的调用则通过接口和依赖注入。至于它们的接口，就应该放在领域层或者应用层。...假设我们的BC都是微服务，就是零共享架构，数据库是独立的。那么，各自BC关心的Product属性应该放在各自数据库中，它们的ID要保持一致。...如果需要组装最后的DTO，则可以在领域服务之上再包装一个应用服务，完成整个完整用例的逻辑。

3.3K40

干货 | 携程机票 React Native 整洁架构实践

二、Clean Architecture Clean Architecture (附录1)是 Uncle Bob 在2012年提出的用于构建可扩展、可测试软件系统的概要原则。...2.3 模块结构 模块内部遵循Clean Architecture原则，分为四层： ViewModel & StatelessView - React框架相关代码，只负责界面展示，样式，动画和传递交互事件...为了让界面逻辑和业务逻辑都能得到合理的表达，参照Clean Architecture 原则，模块内部划分为四层。...Interactor层是对 Model 层的高级封装，多个 Model 之间存在关联性逻辑包含在这层，例如“中转城市”与“仅看直飞”选项的互斥关系。...如果说 Hook 的出现，是为了让开发者更方便地把 state 放入 Component ，那么 Clean Architecture 则是让开发者不要把 state 放入 Component 中。

1.8K30

一篇文章教你读懂UI绘制流程我的Android重构之旅：框架篇

无论什么理由这种创造“上帝类”的方式都应该尽量避免，我们不应该把重点放在编写那些大而全的类，而是投入精力去编写那些易于维护和测试的低耦合类，如果可以的话，最好不要让业务逻辑进入纯净的Android世界，...Clean architecture and The Clean rule 这种看起来像“地壳”的环形图就是Clean Architecture，不同颜色的“环”代表了不同的系统结构，它们组成了整个系统...我们已经选用 MVP 作为框架开发的架构了，这里就不深入的细说 Clean Architecture 架构了，Clean Architecture 的一些优势我们将揉入框架中，我们在框架的设计时应该遵从以下三个原则...：业务逻辑层 看上面的三层我们很容易的就联想到 MVP 结构，下面我就来说一说这三层所包含的内容。...业务逻辑层 业务逻辑层是框架中最重要的一部分，我们在这里解决所有业务逻辑，这一层不应该包含事件走向的代码，应该能够独立使用 Espresso 进行测试，也就是说我们的业务逻辑能够被独立测试、开发和维护，

52421

软件架构编年史：EBI架构

Jacobson 告诉我们，实体对象应该包含和对象自己变同时发生变化的逻辑，例如，如果它的数据结构发生变化，这些数据上的操作也需要改变，因此它们也应该放在实体内。...有意思的是，早在 1992 年，Jacobson 就作出了如下警告： 新手也许有时会让实体对象只携带数据，把所有动态的行为放到控制对象中[...]。然而，这是应该避免的。[...]...它们不能互相取代，它们是对方的补充。如果把它们放在一个模式中，我们可以把它叫做视图-控制器-交互器-实体 (View-Controller-Interactor-Entity)。...Martin – Clean Architecture (NDC 2012) 2014 – Adam Bien – How to tackle JEE 2014 – Ali Parvini – Model...我个人提出的菱形对称架构脱胎于整洁架构思想与六边形架构，实际上也可以认为是对DDD中上下文映射模式的运用，北向网关是开放主机服务，南向网关是防腐层，正是因为菱形对称架构的思想更贴近于DDD，与限界上下文也更加匹配

53710

The Clean Architecture in PHP 读书笔记(七)

Clean Architecture MVC的关键是给我们提出了一个原则：怎么对项目进行合理的关注点分离。...本文为系列文章的第七篇，完成的目录请查看Clean Architecture The Clean Architecture Clean Architecture是Uncle Bob Martin在2012...领域模型和领域服务 在Onion Architecture中最核心是领域模型层，该层只包含了领域模型，彼此之间进行交互，不涉及领域之外的逻辑，在领域模型之外是领域服务层，包括了工厂（factories）...我们可能感慨是使用的Symfony，但是后来要转换为Laravel，如果我们核心设计的好，应该是很方便就能切换过去的。...这是The Clean Architecture in PHP的第七篇，你的鼓励是我继续写下去的动力，期待我们共同进步。

39730

ViewModels and LiveData- Patterns + AntiPatterns

当长期运行的操作结束时，ViewModel中的观察变量会被更新。数据是否被观察并不重要。当试图更新不存在的视图时，不会发生空指针异常。 ViewModels不引用视图，所以内存泄漏的风险较小。...如果你的ViewModel容纳了太多的代码或者有太多的责任，可以考虑。 将一些逻辑转移到与ViewModel相同范围的presenter中。...这将导致一个非常可测试和可维护的架构。它也有利于快速离开主线程。在Architecture Blueprints中有一个Clean Architecture的例子。...例子在这里：https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html ✅ 分散责任，如果需要的话，添加领域层。...旋转是最常见的情况，我们已经用ViewModels覆盖了这种情况。所以，状态被保存在ViewModel中是安全的。

1.1K30

整洁架构、DDD 和 CQRS 简介

同样，我想强调一下我们如何明确地使用依赖倒置原则来确保内部层（纯逻辑和抽象）永远不会有任何外部层（实现）的知识。内部层使用这些层中定义的抽象，而实际的实现逻辑存在于外部层中。...我强烈不同意这一点。应用程序层是它自己的动物，如果需要，您应该始终能够将其与表示逻辑分离。 ◆ 用户界面 用户界面是该架构中绝对最高的概念层。这是用户直接与之交互的代码。...如果答案是“否”，那么您真的需要考虑它是否是一个横切关注点，或者它是否属于系统的另一部分。...一种方法是将命令/查询参数和处理它们的逻辑都放在同一个对象中。该对象使用依赖注入注入每个控制器或使用某种工厂创建。在命令/查询对象上调用Execute()方法并检索结果。我不喜欢这个。...然后我讨论了领域驱动设计如何与 Clean Architecture 结合以产生 Clean DDD，这是一种架构方法，它将 DDD 的方法论和以业务为中心与 Clean Architecture 的逻辑分离相结合

3K20

谈谈代码：DDD从入门到完全入门

比如项目中的数据总线是Kafka，之后替换成了Pulsar，业务对其应该是无感知的。 厚领域层：同一领域的知识聚合在一个领域中，领域知识不再被割裂。这是单一职责原则的一种体现。...：技巧：遵循Clean Architecture写好白盒测试。...5.3 DDD并不是只有三层到四层 也有小伙伴问过我，转DDD的是否只有三层过来的？其实并非如此。...那么按照DDD的做法来，业务逻辑应该与具体的界面无关——比如界面上的一个按钮（数据模型）会触发一种事件，当后台的事件接受者收到这个事件时，则会寻找相应的执行者，执行对应的逻辑。...其本质是用户接口层。 后台的事件接受者是基础层，相对于界面和业务逻辑起到了一个承上启下的作用。 具体的执行逻辑则放在领域层，这是纯粹的逻辑，和UI界面无关。

12210

Mysql引擎介绍及InnoDB逻辑存储结构

可以从上表上看到，InnoDB是唯一支持事务、XA和Savepoints的内置存储引擎。同时，它还支持行锁、外键约束等。...InnoDB的数据逻辑结构 从上面InnoDB的架构图里面的右半部分可以知道，无论是索引还是数据，InnoDB都把它们存在.idb后缀（或者ibdata1）的文件中。...这两种数据组织形式，使得下面两种引擎有如下区别： 1.由于使用聚簇索引，所以无法同时把数据行存放在两个地方，所以一个表只能有一个聚簇索引。...这里有一个有意思的问题，如果InnoDB的二级索引的叶子节点和MyISAM一样，存储的是可以直接找到实际数据的行号，那岂不是可以避免了回表的问题。我个人感觉确实是这样的。...最后说一句(求关注，别白嫖我) 如果这篇文章对您有所帮助，或者有所启发的话，帮忙扫描下发二维码关注一下，您的支持是我坚持写作最大的动力。求一键三连：点赞、转发、在看。

54820

Mysql引擎介绍及InnoDB逻辑存储结构

可以从上表上看到，InnoDB是唯一支持事务、XA和Savepoints的内置存储引擎。同时，它还支持行锁、外键约束等。...内存/磁盘结构及存储逻辑结构 InnoDB总体架构 https://dev.mysql.com/doc/refman/5.5/en/innodb-architecture.html 上面这张图是InnoDB...InnoDB的数据逻辑结构 从上面InnoDB的架构图里面的右半部分可以知道，无论是索引还是数据，InnoDB都把它们存在.idb后缀（或者ibdata1）的文件中。...这两种数据组织形式，使得下面两种引擎有如下区别： 1.由于使用聚簇索引，所以无法同时把数据行存放在两个地方，所以一个表只能有一个聚簇索引。...这里有一个有意思的问题，如果InnoDB的二级索引的叶子节点和MyISAM一样，存储的是可以直接找到实际数据的行号，那岂不是可以避免了回表的问题。我个人感觉确实是这样的。

48310
点击加载更多

扫码

添加站长 进交流群

领取专属 10元无门槛券

手把手带您无忧上云

扫码加入开发者社群

相关资讯

热门标签

更多标签

活动推荐

    运营活动

    活动名称
    广告关闭

    腾讯云开发者

    扫码关注腾讯云开发者

    扫码关注腾讯云开发者

    领取腾讯云代金券

    热门产品

    热门推荐

    更多推荐

    Copyright © 2013 - 2024 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有

    深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 深公网安备号 44030502008569

    腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号 | 京公网安备号11010802020287

    领券