这或多或少是一个以框架为中心的版本 past Stack Overflow question ，这是关于 MVC 应用程序的大多数介绍性 Material 如何倾向于呈现模型、 View 和 Controller 之间的紧密耦合。例如，您将有一个由用户 Controller 修改的用户表，用户 Controller 又将过滤后的数据推送到用户 View 。我的印象是很多 MVC 框架也倾向于反射(reflect)这种模式。就其本身而言，这一切都很好，但除了使用 HTML 表单构建和显示单调的事物列表之外，它从未真正引导我去做任何事情。
现在看的MVC框架是Lithium ，作为巧妙的 PHP5.3 编码技术的案例研究，这似乎很有趣。一方面，Lithium 有一个 Model 类，它提供围绕单个表的包装对象，并抽象出一些简单的查询。另一方面，它有一个漂亮的约定，将 URL 路由到 Controller 对象的方法调用，然后呈现以显示模板。
但在此过程中，我发现自己不知道将表 A 中的数据与表 B 到 Z 中的数据相关联的所有有趣逻辑放在哪里。或者至少，我不确定放在哪里以与框架设计一致的方式放置此类逻辑。据我了解，Lithium 的Model 抽象只是消除了一些行级插入/更新/删除样板，而 Controller / View 架构似乎主要与用户界面有关。我不想将大量业务逻辑放在从 URL 请求接收路由函数调用的同一个 Controller 类中。
我的直觉是用我自己的代码来填补空白，这些代码或多或少完全存在于框架之外。我不确定我是否应该期待更多，但考虑到 Lithium 中其他所有东西的结构是多么严格，我感觉有点不满意，就像我可以直接推出我自己的样板缩减代码而无需摸索源代码的开销一个大框架。
我在这里错过了什么？是否有使用此类框架的推荐架构或理念？
最佳答案
关于 Lithium，您必须记住的一件事是，目前还没有生产就绪版本(尽管一些站点正在生产中使用它)。 现在主要缺少的功能是模型关系。有了适当的关系，我假设您的问题将得到部分回答，因为这是创建更复杂应用程序的大局中的重要组成部分。 您可以查看应该正在进行关系工作的 x-data 分支。
对于编写域逻辑的第二部分，简单的答案是“在模型中”。 参见 this (rather useless) example of extending model functionality例如。 另一个要看的例子是开源迷你应用程序 Analogue，它是正在使用的 Lithium 的少数工作开放示例之一。 Analogue model class展示了稍微多肉的模特。
最后是连接 M、V 和 C 之间的点的问题。 Lithium Controller 应该主要将工作委托(delegate)给模型，并可能在需要时重组输入数据。 拥有 Post 模型、PostsController 和 views/posts/add、index 等的简单示例并不意味着您必须只在其中包含 Post::all()。 PostsController::view 可能需要加载一组 Comment 模型。
所以你当然会在里面扔很多你自己的代码!否则它不会是一个很大的应用程序。但要将领域逻辑与模型联系在一起，这是很自然的。
- 需要验证博文有 独特的标题？写一个验证器。
- 需要确保用户对帖子具有写入权限？覆盖保存方法并验证它，或过滤它。
但我认为我们需要等待关系落地和 1.0 版本发布，然后我们才能完全判断如何最好地解决 Lithium 中的结构化应用程序。
关于php - 超越 CRUD 的锂应用程序，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/4667741/