根据意图而不是架构构建程序 - Janos Pasztor

19-01-09 banq
              

在查看代码时,我经常会看到MVC模式:模型,视图,控制器,表单等文件夹。表面上看起来不错,对吗?您将控制器放在控制器文件夹中,模型文件夹中的模型等等。这对于像博客这样的小型示例应用程序来说相当不错,因为您可能有5个控制器,6个模型等等。

但是,当您在更大的应用程序上工作,或者您遵循一个控制器的概念 ,一个action时,这些文件夹中的这些文件数量会迅速升级,并成为命名问题的混乱。

推荐谈话: 罗伯特“鲍勃叔叔”马丁 - 建筑:失落的岁月

我们来看一个社交媒体项目的例子。你有Walls,WallPosts,评论,PrivateConversations, PrivateConversationMessages以及更多东西。使用“经典”排列,我们将拥有相当大的目录树,即使没有前面提到的方法:

SRC
调节器
WallController
WallPostController
CommentController
PrivateConversationController
PrivateConversationMessageController
模型
WallModel
WallPostModel
CommentModel
PrivateConversationModel
PrivateConversationMessageModel
视图

...

这只是一个简单的例子,在现实世界中的应用程序,你就会有很多更多的控制器,模型和视图。如果根据应用程序的构造(模型,视图,控制器)进行构建,则在某个奇点之后,目录结构将变得完全无法使用。

当然,您可以使用IDE的搜索功能,但是重载的目录结构会导致您感觉有太多的类。这种感觉反过来导致害怕添加新类,您的开发人员会尝试将新功能填充到现有类中,即使它不严格属于那个类,从而导致很多单一责任原则违规。此外,这种结构使得团队中的新开发人员难以了解什么是什么。

基于意图的结构

如果我们仔细观察我们的控制器,我们可以在属于一起的东西和不属于哪些东西之间绘制线条。例如,从商业角度来看,Wall似乎是一个非常明确的概念:人们可以拥有一面墙,在上面写帖子和对所述帖子发表评论。因此,让我们将与墙相关的所有内容放入一个文件夹中。类似:

[b]src[/b]
<p>[b]wall[/b]
CommentController
CommentModel
WallController
WallPostController
WallModel
WallPostModel
<p>[b]conversation[/b]
PrivateConversationController
PrivateConversationModel
PrivateConversationMessageController
PrivateConversationMessageModel
...

仍然不是很好,但更好。现在可以扩展目录结构而不必担心太多的类,如果我们正在寻找一些东西,我们可以在哪里找到它。

在我们继续之前,让我们澄清一件事:这些“模块”不是独立的。有时,如果您希望单独发布模块,它们可能具有可能需要解决的交叉依赖性,但这是另一篇文章的主题。

您可能会注意到,现在模块中的所有内容都被拿出到另外一个目录中。这很好,因为它(希望)会阻止你在一个模块中添加太多东西。但是,如果你像我一样,你仍然喜欢有一些结构构建块,所以让我们带回以前的目录结构,但是低一级:

SRC
wall
 控制器 
   CommentController
   WallController
   WallPostController
模型
  CommentModel
  WallModel
  WallPostModel
视图
...
会话
...

易于浏览和易于阅读的代码块。当然,您可以在您感觉舒适的同时,以层次结构的方式继续添加业务结构。我建议你将它保持在3-5级以下,以便轻松导航。

提示: MVC不适合作为您的总体设计模式。相反,我建议看一下 Entity-Boundary-Interactor

总而言之,您最外层的文件夹结构应该基于业务概念(意图),而不是您选择使用的设计模式。​​​​​​​