我远不是MVC V领域的专家，并且最近一直在尝试不同的视图，我目前正在尝试的那个甚至可能不是一个有名字的正确视图，这只是我想出的东西
在我的申请中，Customer可以向Request发送Courier（投放请求）。
Request有4种状态：
我有一个RequestView扩展了我的View。我在Request构建RequestView时注入一个Request实体，并根据RequestView中RequestView的状态选择合适的模板。
我的protected function getStateText() {
switch( $this->request->getState() ) {
case Request::STATE_SENT:
return 'Sent';
case Request::STATE_CANCELLED:
return 'Cancelled';
case Request::STATE_REJECTED:
return 'Rejected';
case Request::STATE_ACCEPTED:
return 'Accepted';
default:
return 'Error';
}
}
有一些方法，如：
echo $this->getStateText();
然后我可以通过调用
在我的模板中使用它Request在getStateText()实体中，我只使用INTEGER处理状态，当我在表示层时，没有人想要以数字格式查看状态，他们希望在文本中看到当前状态，以便这就是我在表示层而不是在实体本身中使用{{1}}方法的原因。我的思考/推理是否正确？
我目前的实施是好还是坏？这种类型的View有名字吗？
感谢。
答案 0 :(得分：1)
首先，为什么模板中的$this指向一个视图？然后，当我使用“模板”一词时，我的意思是this。
另外，我对视图中注入Request实例背后的原因感到很困惑。如果视图需要来自模型层的数据，则应该仅查询所述数据。然后，如果您在该视图中有一些共享的可视化逻辑，则可以将其简单地隔离到适当的presentation object。
那些演示文稿对象（Fowler称之为“演示模型”，我发现它只会增加混淆）然后可用于生成可以应用于模板的值。
这些都与MVVM无关。当您更换Controller时，ViewModel就是您在该模式中使用的模式。这一般不会触及视图。此外，MVVM模式更接近MVP，而不是其他任何东西。如果你添加MVP，一个监督控制器，页面控制器然后让一个崇拜Rails的人动摇它，你就会得到它。
至于命名你现有的东西，不幸的是我只是将它标记为“SRP违规”并继续戳它。
我的2美分
答案 1 :(得分：0)
此类型的视图是否有名称？
您正在冒险迈向MVVM（Model-View-ViewModel）
我目前的实施是好还是坏？
根据你所展示的内容，我认为你正朝着正确的方向前进，因为我会说你做得很好。
我要做的一件事就是将getStateText逻辑放在另一个类中（例如RequestStateToTextTransformer =＆gt; transform和reverseTransform方法）。
为什么呢？好吧，也许你想在其他地方以不同的格式显示Request实体。您目前必须在不同的ViewModel中复制getStateText代码。使用变压器，没有重复。