【发布时间】：2015-09-30 08:18:55
【问题描述】：
在 Symfony/Doctrine/PHP 项目中，客户抱怨我们违反了软件开发最佳实践。投诉是关于源代码分层不当，以及缺乏单元测试。
- 这是一个低于 5 万美元的项目。
- 我相信客户有来自 Java 世界的专家，可能是 Spring Framework，正在查看源代码。
正如我们所见，我们一直在使用正确的 MVC。
- 视图逻辑完全由 TWIG 处理。
- 数据库完全由 Doctrine 处理。
- 我们正在使用 Symfony Security 进行访问控制
($this->get('security.context')->isGranted('ROLE_ADMIN')和$this->get('security.context')->getToken()->getUser()。
请注意，自从我们开始这个项目以来，Symfony 已经稍微改变了模型 - 但仍然向后兼容。
在控制器中，客户明确表示控制器处理错误：
- 访问控制（通过 Symfony Security）
- 数据库查询（通过 Doctrine）
- “解析和其他逻辑”用于发回响应 (
return $this->render('some_template.html.twig');)
问题
客户说最佳实践是让控制器简单地将请求传递到系统中的另一层。
他还说用户管理员基于“自定义模型”，其中所有用户和角色都存储在数据库中 - 这使得插入不同的访问控制系统变得困难。特别是因为角色名称似乎是硬编码的，例如通过 ($this->get('security.context')->isGranted('ROLE_ADMIN') 等命令。
所以;在这个领域有明确的最佳实践吗？属于控制器的，是 Doctrine、Twig、Symfony Security “足够”在“控制器之下”的一个单独层。
例如，控制器和 Doctrine 之间是否应该再有一层？
【问题讨论】：
-
我想说，如果单元测试不是明确的约定交付物，客户就不能坚持使用它们（参见 Freelancing 上的this related discussion）。你有功能测试吗？如果您希望提供其中之一，那么我会提供功能测试，因为单元测试本身并不能证明您的应用程序按预期工作。
-
您应该在实体存储库或其他模型格式中，而不是在控制器中进行学说查询。访问控制通常在控制器中完成，然后由该控制器运行特定于访问的功能。渲染模板是控制器的工作，也可以在模板中完成，以整合模板片段。
-
“控制器处理是错误的”“数据库查询（通过 Doctrine）”——它们是绝对正确的。
-
@frodeborli 不，它没有 - 您的控制器应该不知道使用的特定类型的存储。 “控制器有一些逻辑”——他们不应该。根据 MVC 定义，它们只是模型和表示层之间的粘合层。 “模型层”不仅仅是你的存储库和实体，它是所有的业务逻辑。
-
一切都“正确”完成的一个好兆头是，如果您可以轻松添加新的用户界面，例如：CLI。您能否添加 CLI 以廉价的方式提供您的项目作为 Web 应用程序提供的所有功能？
标签： php symfony model-view-controller doctrine-orm