干净架构中演示层、领域层和数据层模型类的命名规范

11

我有演示、域和数据模块。我从体育API获取足球运动员信息。我使用一个映射器类在模块层之间映射数据类。

我只是想知道在不同模块中命名数据类的约定是什么。

在我的数据层中,我将从API中提取球员信息并将其保存在本地。

Data Layer
local:
    PlayerTable
    
repository:
    PlayerEntity
        
Domain Layer
    PlayerModel
    
Presentation
    Player

我刚刚给TableEntityModel添加了后缀。至于Presentation Player,它就是它本身。

只是想知道有没有特定的约定。我见过有人这样做,但最重要的是保持一致性。

只是想知道其他开发人员在为他们的数据类命名时都做了什么。

感谢任何建议,

2个回答

12

关于如何为类命名,没有官方的命名方案。但在大多数语言中:

  • 类名应该以大写字母开头
  • 变量名应该以小写字母开头
  • 常量应该全部使用大写字母和下划线

一些开发者会像这样给变量添加前缀:

  • mVariable 代表类的公共成员变量
  • _variable 代表类的私有变量
  • _variable 代表类内的后备字段
  • sVariable 代表单例字段

个人认为不需要使用这些前缀,因为这些前缀是在我们拥有语法高亮之前的遗物。现在我们的IDE可以对所有内容进行着色,所以很容易区分类名、变量名等。

最终如何组织代码取决于你自己,随着每个项目的推进,你会逐渐改进和调整代码。有时候你会在一个有固定代码规范的团队中工作,在这种情况下,代码规范甚至可能会被Lint规则执行。

从以下几个角度考虑:

  • 两年后,未看过此代码:通过只读取其名称,您能否知道该类的作用是什么?

  • 将类名尽可能缩短,但要足够明确。例如,如果一个类已经在名为model的包中,则无需将其命名为PlayerModel。在大多数情况下,只使用Player即可。

  • 你的代码是给未来的自己写的情书。如果几年后再读它,你会喜欢自己还是厌恶自己(后者更常见)。

  • 其他不知道您的类是干什么的开发人员能否理解它的责任。

最重要的是:

永远不要害怕重构!如果您意识到名称不合适,就改名吧。

另一个好提示:

阅读一些关于清晰代码的书籍。我推荐“The pragmatic programmer”和当然是臭名昭著的“Clean Code”。

希望这可以给您在这个主题上提供一点指导!祝编码愉快 :)

更新:

如果您遇到在1个文件中使用了相同名称的两个类的情况,则大多数语言提供“导入别名”的功能。例如,在Java中,您可以在导入语句中输入:

import some.file.from.network.Player as NetworkPlayer
import model.class.from.my.app as AppPlayer

您可以使用别名AppPlayerNetworkPlayer引用文件中的两个不同类,以便清楚易懂地区分它们。


谢谢您的回答,但我真正感兴趣的是演示层、领域层和数据层中数据类的命名约定。 - ant2009
不客气 :) 这就是我添加更新的原因。关于 PlayerModelPlayer 的问题是针对你的问题而写的。简短回答:没有官方约定。最佳实践是创建自己的约定,并在每个项目中严格遵守它。 - muetzenflo
也许可以实现一个lint检查器或类似的静态代码分析工具来强制执行你的规则。看着你的SO分数,我相信你知道在哪里找到这些东西 ;) - muetzenflo

1
我认为,清晰架构是一种设计系统的哲学,旨在使其易于阅读、易于理解,并具有明确定义的职责分工。
如果我们遵循这种哲学,一些模型/类/实例永远不应该交叉。这意味着数据库模型将不会存在于与展示模型相同的上下文(java文件、python模块等)中。因此,很常见看到人们使用最明显的名称来实现这一点,并使上下文成为分类器。
例如,如果您有一个表示玩家的数据模型,则处理它的类的明显名称是Player,并具有反映数据库处理性质的命名空间(或包),如database.Player或database.models.Player。 展示层也是如此。

关于实体,我遵循完全相同的规则。我总是有一个命名空间core(这是我个人的偏好),在其中存储所有实体和用例的代码。这个核心命名空间可以有其他子命名空间,并且不导入第三方代码(或保持最小的依赖关系)。在这种情况下,如果我需要一个代表玩家的实体,我会将其称为Player。外部层与核心通信所需的接口在这里定义,并且仅依赖于实体。

唯一的情况是,外部层可以与实体代码通信,就是在实现核心接口时。在那里,我实际上遵循@muetzenflo的建议,在导入时给我的实体取个别名,或使用命名空间(entities.Player)。

我不确定是否真的存在一种惯例,也不确定是否真的需要一种惯例。最终目标是使代码易于理解、易于维护和易于开发。如果我们有理由放弃一些指南,以便做得更好、更可靠、更易于阅读和维护,那就这样吧。


网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接