Jef*_*Lee 6 php model-view-controller lithium
这或多或少是过去Stack Overflow问题的以框架为中心的版本,该问题是关于MVC应用程序的大多数介绍性材料如何在模型,视图和控制器之间呈现紧密耦合.例如,您将拥有一个由用户控制器修改的用户表,用户控制器又将过滤后的数据推送到用户视图.我的印象是很多MVC框架也倾向于反映这种模式.这一切都很好,很好,但除了用HTML表单构建和显示单调的事物列表之外,它从来没有真正引导我.
现在正在研究的MVC框架是Lithium,它作为巧妙的PHP5.3编码技术的案例研究似乎非常有趣.一方面,Lithium有一个Model类,它在各个表周围提供包装器对象,并抽象出一些简单的查询.另一方面,它有一个很好的约定,即路由URL到控制器对象上的方法调用,然后呈现给显示模板.
但是在这期间,我发现自己不知道将表A中的数据与表B到Z中的数据相关联的所有有趣逻辑放在哪里.或者至少,我不知道在哪里放置这样的逻辑的方式与框架的设计一致.根据我的理解,Lithium的Model抽象除了消除一些行级插入/更新/删除样板外没什么作用,控制器/视图架构似乎主要是关于用户界面.我不想在Controller从URL请求接收路由函数调用的同一个类中放入大量业务逻辑.
我的直觉是用一堆我自己的代码填补空白,这些代码或多或少完全存在于框架之外.我不确定我是否应该期待更多,但考虑到Lithium中其他所有内容的结构是如何严格的,它感觉某种程度上不令人满意,就像我刚刚推出了自己的样板减少代码而没有花费很多资源来解决这个问题.一个大框架.
我在这里错过了什么？是否有推荐的架构或哲学来使用这种类型的框架？
你必须要记住的一件事就是没有生产就绪版本(尽管有些网站正在生产中使用它).现在主要的缺失特征是模型关系.有了关系,我认为你的问题会得到部分回答,因为这是创建更复杂应用程序的重要组成部分.您可以查看关系工作应该在哪里的x-data分支.
对于编写域逻辑的第二部分,简单的答案是"在模型中".例如,请参阅扩展模型功能的这个(相当无用的)示例.另一个值得关注的例子是开源迷你应用程序Analogue,它是使用中少数工作开放的锂的例子之一.该模拟模型类显示一个稍微肉模型.
最后是连接M,V和C之间的点.锂控制器应该主要将作业委托给模型,并且如果需要可能重新构造输入数据.使用Post模型,PostsController和views/posts/add,index等的简单示例并不意味着您必须只有Post :: all().PostsController :: view需要加载一组Comment模型.
当然,你会在那里抛出很多自己的代码!否则它不会是一个应用程序.但是保持域逻辑与模型紧密相关.
但我认为我们需要等待关系到达并发布1.0版才能完全判断如何最好地解决Lithium中的结构化应用问题.