6

这或多或少是过去 Stack Overflow 问题的以框架为中心的版本，该问题是关于 MVC 应用程序的大多数介绍性材料如何倾向于呈现模型、视图和控制器之间的紧密耦合。例如，您将拥有一个由用户控制器修改的用户表，该用户控制器反过来将过滤后的数据推送到用户视图。我的印象是很多 MVC 框架也倾向于反映这种模式。就其本身而言，这一切都很好，但除了使用 HTML 表单构建和显示单调的事物列表之外，它从未真正引导我做任何事情。

现在看到的 MVC 框架是Lithium，作为一个聪明的 PHP5.3 编码技术的案例研究，这似乎很有趣。一方面，Lithium 有一个Model类，它提供围绕单个表的包装对象，并抽象出一些简单的查询。另一方面，它有一个很好的约定，将 URL 路由到控制器对象上的方法调用，然后渲染到显示模板。

但在此过程中，我发现自己不知道将表 A 中的数据与表 B 到 Z 中的数据相关联的所有有趣逻辑放置在哪里。或者至少，我不确定在哪里放置这些以与框架设计一致的方式实现逻辑。据我了解，Lithium 的Model抽象只是消除了一些行级插入/更新/删除样板，而控制器/视图架构似乎主要与用户界面有关。我不想将大量业务逻辑放在Controller从 URL 请求接收路由函数调用的同一个类中。

我的直觉是用我自己的代码来填补空白，这些代码或多或少完全存在于框架之外。我不确定我是否应该期待更多，但考虑到 Lithium 中其他所有东西的结构非常严格，感觉有点不满意，就像我本可以推出自己的样板减少代码，而无需花费大量时间来探索源代码一个大框架。

我在这里想念什么？使用这种类型的框架是否有推荐的架构或理念？

4

1 回答 1

8

对于 Lithium，您必须记住的一件事是目前还没有生产就绪的版本（尽管有些网站正在生产中使用它）。现在主要缺少的功能是模型关系。有了适当的关系，我假设您的问题将得到部分回答，因为这是创建更复杂应用程序的大局中的重要砖块。您可以查看应该进行关系工作的 x-data 分支。

对于编写域逻辑的第二部分，简单的答案是“在模型中”。例如，请参阅扩展模型功能的这个（相当无用的）示例。另一个值得关注的例子是开源迷你应用 Analogue，它是少数几个使用中的 Lithium 开放示例之一。Analogue 模型类显示了一个更丰富的模型。

最后是连接 M、V 和 C 之间的点的问题。锂控制器应该主要将工作委托给模型，并在需要时可能重构输入数据。拥有 Post 模型、PostsController 和 views/posts/add、index 等的简单示例并不意味着您必须只在其中拥有 Post::all()。PostsController::view 可能需要加载一组评论模型。

所以你当然会在里面扔很多你自己的代码！否则它不会是一个应用程序。但保持领域逻辑与模型自然相关。

  • 需要验证博客文章是否具有唯一标题？编写一个验证器。
  • 需要确保用户对帖子有写入权限？覆盖 save 方法并验证它，或过滤它。

但我认为我们需要等待关系落地和 1.0 版本发布，然后才能完全判断如何最好地解决锂中的结构化应用程序。

于 2011-01-12T18:15:02.137 回答