【问题标题】:Eloquent ORM Active Record - Is this the right approach?Eloquent ORM Active Record - 这是正确的方法吗?
【发布时间】:2018-07-24 00:45:06
【问题描述】:

自从我开始反抗并质疑我所学的一切以来,我认为我终于进入了代码青春期。我希望这里有人能指出我正确的方向。目前,什么应该是简单而简短的任务,最终要花费数小时,因为我坐着盯着几行代码并质疑这是否确实是正确的方法......

这是一个例子。我们有一个系统可以让User 在该帖子中创建PostMention 某人。我们有一个控制器来获取请求,然后将其发送到 PostService,该 PostService 具有如下方法:createPostByUser(int $id, string $title, string $content),最终发送到保存帖子的$postingUser->post($title, $string)

在 createPostByUser 方法中,我们将检查是否有任何@mentions,然后我们会将其传递给 MentionService。因此,在这种情况下,我们将访问:$mentionService->createMentionByUser(int $id, string $username, Mentionable $mentionable) 然后检查提及用户 ($id) 和提及用户 ($username) 是否存在,或者甚至可能恢复提及(如果存在但被软删除)。如果它不存在并且无法恢复并且两个用户都有效,那么我们将继续调用 $mentioningUser->mention($mentionedUser) 来保存提及。

虽然所有这些都有效,但我开始发现它存在一些问题。什么会阻止新开发人员跳过服务层直接进入用户对象并使用这些方法?我的意思是,在 MentionService 中,我们在保存提及之前检查一切是否正常,例如检查需要的两个用户是否有效,是否应该恢复提及。等等。什么会阻止一个新的不知情的开发人员直接进入用户对象并不加思索地创建一个新的提及?

希望有人能指出我正确的方向。我们在正确的轨道上吗?

我只是想太多了吗?

【问题讨论】:

    标签: php database laravel activerecord eloquent


    【解决方案1】:

    我认为这个问题无法以技术方式解决。任何设计模式和任何架构风格都可能以某种方式被误解和故意规避。这个问题可能可以在组织层(在您的团队中)解决。一种可能性是,例如代码审查培训文档。最重要的是带有分支和拉取请求的代码审查。随着时间的推移,您可以为新开发人员实现学习效果并防止新的失败。

    【讨论】:

      【解决方案2】:

      我的观点是,您首先要问自己您正在构建什么样的软件/应用程序。如果您正在构建Enterprise 应用程序,我将使用Services,因为您的Services 将包含业务逻辑,而您的Controllers 将包含应用程序逻辑,这可以让您将这两者分开,它将极大地帮助您稍后调试代码随着应用程序的增长。如果您正在构建一个基本的CRUD 应用程序,那么我认为创建Services 没有意义,但同样,这只是我的意见,因为有no right approach,它真的是情境。

      【讨论】:

      • 感谢您的回答。正如你所说,它的情境,所以没有正确的解决方案,但我的问题主要适用于我目前的工作。我们是一个半大型社交媒体,每天有 5-1 万新用户。所以很多事情都会出错!在基本的 CRUD 中,我不会考虑太多,但在我们的平台上,情况就不同了。如果事情出错,那么付出代价的不仅仅是我们。
      猜你喜欢
      • 1970-01-01
      • 2013-09-25
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2011-02-17
      • 2010-11-09
      • 2012-03-26
      相关资源
      最近更新 更多