the*_*zer 155 ruby model-view-controller ruby-on-rails
在Ruby on Rails开发(或一般的MVC)中,我应该遵循什么快速规则来放置逻辑.
请回答是肯定的 - 把Do放在这里,而不是把它放在那里.
pau*_*nic 171
MVC
控制器:在这里放置代码,用于解决用户想要的问题,决定给他们什么,确定他们是否登录,他们是否应该看到某些数据等.最后,控制器查看请求并确定要显示的数据(模型)和要呈现的视图.如果您对代码是否应该进入控制器存在疑问,那么它可能不应该.让你的控制器变瘦.
视图:视图应该只包含显示数据的最小代码(模型),它不应该进行大量的处理或计算,它应该显示模型计算(或汇总)的数据,或者从Controller生成.如果您的View确实需要执行模型或控制器无法完成的处理,请将代码放在Helper中.View中的大量Ruby代码使得页面标记难以阅读.
模型:您的模型应该是您的所有与您的数据相关的代码(构成您网站的实体,例如用户,帖子,帐户,朋友等)的所在地.如果代码需要保存,更新或汇总与您的实体相关的数据,请将其放在此处.它可以在您的视图和控制器中重复使用.
jco*_*oby 35
添加到pauliephonic的答案:
助手:使创建视图更容易的功能.例如,如果您总是迭代小部件列表以显示其价格,请将其放入帮助程序(以及实际显示的部分).或者,如果你有一块你不想让视线混乱的RJS,那就把它放到帮手里.
Sør*_*und 14
MVC模式实际上只关注UI而不是其他任何东西.您不应该在控制器中放置任何复杂的业务逻辑,因为它控制视图而不是逻辑.Controller应该关注选择正确的视图并将更复杂的东西委托给域模型(Model)或业务层.
领域驱动设计有一个服务概念,这是一个你坚持逻辑的地方,它需要协调许多不同类型的对象,这通常意味着逻辑不自然地属于Model类.
我通常认为Service层是我的应用程序的API.我的服务层通常非常接近我正在创建的应用程序的要求,因此服务层可以简化我的应用程序的较低级别中发现的更复杂的交互,即您可以绕过服务层实现相同的目标但你必须拉出更多杠杆才能使其发挥作用.
请注意,我不是在谈论Rails,而是在讨论解决您特定问题的一般架构风格.
mad*_*ode 11
这里有完美的解释,一个非常简单的句子作为结论,易于记忆:
我们需要SMART模型,THIN控制器和DUMB视图.
http://c2.com/cgi/wiki?ModelViewController
将与授权/访问控制相关的内容放入控制器中.
模型都与您的数据有关.验证,关系,CRUD,业务逻辑
视图是关于显示您的数据.仅显示和获取输入.
控制器用于控制从模型到视图(以及哪个视图)以及从视图到模型的数据.控制器也可以不带模型存在.
我喜欢将控制器视为一名保安/接待员,他将客户(请求)引导到您询问出纳员(查看)问题的相应柜台.出纳员(查看)然后去找一个你从未见过的经理(模特)的答案.你的请求然后回到保安/接待员(控制器)并等到你被指示去另一个出纳员(查看)谁告诉你经理(模型)告诉他们回答其他出纳员(查看)问题的答案.
同样,如果你想告诉出纳员(查看)一些东西,那么大致相同的事情会发生,除了第二名出纳员会告诉你经理是否接受了你的信息.保安/接待员(控制人)也可能告诉您加息,因为您无权告知经理该信息.
因此,为了扩展这个比喻,在我的刻板印象和不切实际的世界中,出纳员(观点)很漂亮但是空头而且经常相信你告诉他们的任何事情,保安/接待人员都是极端礼貌但不是很了解,但他们知道人们应该在哪里和不应该去,管理者真的很难看,但他们知道一切,可以说出什么是真的,什么不是.
| 归档时间： |
|
| 查看次数： |
42035 次 |
| 最近记录： |