MVC - 除了set/get成员之外,哪些方法应该在Model类中？

Question

在Model类memebers 上进行操作的方法应该在Model上还是在Controller中实现 ？这取决于这种操纵的"重"程度如何？

"操纵"我的意思是 - 获得一个类成员,根据他进行长时间计算,然后返回与该类相关的另一个值.

例如 - 具有Board class保持单元矩阵成员的现在,我想实现一种根据特定单元位置返回所有周围单元的方法.谁负责实施上述？

如果此问题属于另一个Stack Exchange QA,欢迎发送帖子.

Answer 1

保持控制器的精简,不要让它们做得太多,这与面向对象设计的SOLID中的单一责任原则相一致.如果你有胖控制器,它们就很难测试和维护.

至于模型,我曾经有过愚蠢的模型,除了映射到数据库表之外什么也没做,这是受到你在网上看到的大多数示例应用程序的启发,但现在我不这样做.

我(尝试)遵循域驱动设计的原则,其中模型(DDD术语中的实体)位于应用程序的中心,他们期望封装与实体相关的行为,它们是智能模型(是的,逻辑在这种情况下,与一个对象相关的将与它一起生活).DDD是一个更大的主题,它与MVC没有直接关系,但它背后的原理可以帮助您更好地设计您的应用程序,如果您使用谷歌DDD,有很多材料和示例应用程序可用.

此外,Ruby On Rails社区 - 似乎激发了大多数MVC框架 - 似乎也有关于Fat Models和Skinny Controllers的大肆宣传.

最重要的是,您可以将View Models添加到我认为有用的混音中.在这种情况下,您可以使用ViewModel来表示模型的哑子集,仅用于生成视图,它可以让您的生活更轻松,并进一步将您的视图与模型分开,这样它们就不会影响您的设计不必要的决定.

Answer 2

你所谓的"模型"实际上是域对象.MVC中的实际模型只是一个层次,而不是具体的事情.

在您的特定示例中,Board应该有一个返回此列表的方法.我假设你实际上正在获取它,因为你需要与这些单元格进行进一步的交互.

这是模型层中的服务可以使用的地方.如果使用它们,它们是模型层的外部部分,包含应用程序逻辑 - 不同域对象之间的交互以及持久性(通常是数据映射器或工作单元)与域对象之间的交互.

假设您正在制作游戏,并且您和玩家执行AoE攻击.控制器负责服务,负责此功能并发送命令:此玩家将AoE指向此方向,执行它.

服务实例化Board并询问目标位置的周围单元.然后它对它获得的集合中的每个单元格执行"损坏".逻辑完成后,它会告诉工作单元实例提交所有更改,这些更改发生在Board.

控制器不关心服务的细节.它不应该收到任何反馈.当执行到达视图时,它从模型层请求最新更改并修改UI.作为附加的好处 - 服务可以让您阻止业务逻辑在表示层中泄漏(主要由视图和控制器组成).

域对象应该只包含处理其状态的方法.

Answer 3

我认为这与MVC没什么关系,而且与常规软件工程有很多关系.

我个人会毫不犹豫地在一个模型中坚持琐碎的计算,但会对胖模型非常警惕.

现在,MVC代表模型视图控制器的事实并不一定意味着一切都应该是视图,模型或控制器.如果你觉得有必要将责任转移到一个不具备M,V或C的独立类别,我不明白为什么你不应该这样做.

你实现它的方式取决于你.您可以将此单独的类用作"顶级"(缺少更好的术语)对象,或者将模型的方法委托给它,以隐藏您正在使用它的事实.我可能会选择后者.

但是,一切都值得商榷.每个人和他们的妹妹似乎对如何正确地进行MVC有不同的看法.

我,我只是认为它是一个指导方针.当然,这是一个好主意,因为它会引导你更好地分离关注点,但最终 - 因为它总是发生 - 没有一种通用的方式来应用它,你不应该过度约束它,一切都必须是视图,模型或控制器.