ezu*_*zuk 2 model-view-controller ruby-on-rails
我有一个toys控制器,用户可以用来声称玩具玩.现在,该claim方法是在控制器级别实现的(正如我的回答所建议的那样).
然而,现在它变得有点胖,声称逻辑真的不应该存在:如果孩子已经有3个玩具,孩子不能要求玩具,孩子不能要求另一个孩子声称的玩具,等等.这种逻辑(在我看来)的合理位置在child模型中,因为我描述了孩子的行为(他们可能会做什么,也可能不行).
也就是说,如果我这样做,toys#claim控制器动作将从child模型中调用方法.这是代码气味/不良做法吗？
(我猜有人会建议我使用服务对象.如果你这样做,请指出一个简单的教程？最近关于这个的RailsCast对我来说有点太复杂了.)
提前致谢!
一般来说(在Rails之外),它根本就不是气味.事实上,我认为在"模型"和"控制器"之间进行纯粹的1:1映射是一种气味.
注意:我不是ROR开发者.我没有ROR经验或者它是如何实现的.但是,我确实很了解设计模式,并了解应用程序架构.照这样说:
而不是担心1:1映射,退一步思考应用程序的结构.
控制器应该做什么？嗯,通常它应该将用户操作路由到应用程序.这只是一个管道步骤.
那么什么是模型(层)应该做什么？通常,Model是一个包含应用程序中所有业务逻辑的层.它将处理数据库交互,访问控制,业务操作等.因此,该模型实际上是您的应用程序的绝大多数.
另一方面,视图是您的表现层.它应该处理所有渲染,从模型层提取数据.
基于这种理解,您的模型,视图和控制器应该能够彼此独立地变化.一般来说,我希望在控制器和视图之间看到一个相当1:1的关系.我的意思是存在的每个控制器,我希望看到一个视图.但是可以存在没有用户交互的视图.在这些情况下,您可能需要一个控制器(用于渲染视图),或者根据您的体系结构,您可能需要一个控制器.
但是"模型类",它们是模型层的一小部分(充当较低模型功能的代理或适配器),可能与控制器或视图成1:1.例如,您可能有一个从多个模型中提取数据的视图.您可以拥有一个可以作用于多个模型的控制器.
现在你可以退一步说,如果控制器需要对多个模型进行操作,那么创建一个抽象该操作的新模型.有时这是正确的做法.有时它不是.这一切都归结为具体的操作和涉及的关系......
在一天结束时,这里没有"正确"或"错误".在构建应用程序时,您需要做出一个设计决策.我不会太担心"气味"组件,只要它在你的应用程序中有意义......
| 归档时间： |
|
| 查看次数： |
134 次 |
| 最近记录： |