胖模型和瘦控制器听起来像是在创建上帝模型
我读了很多博客，它们提倡胖模型和瘦控制器的方法，特别是。Rails阵营。因此，路由器基本上只是确定在什么控制器上调用什么方法，而控制器方法所做的就是在模型上调用相应的方法，然后显示视图。所以我这里有两个我不理解的问题：
- 控制器和路由器除了在基于路由的类似上帝的模型上调用方法之外，实际上并没有做太多不同的任务。
- 模型做的太多了。发送电子邮件、创建关系、删除和修改其他模型、将任务排入队列等。基本上，现在您有了上帝般的对象，它们应该执行与建模和处理数据相关或不相关的所有任务。
你在哪里划清界限？这难道不是落入了上帝的模式吗？
回答 2
Stack Overflow用户
发布于 2012-12-27 03:08:24
如果"model“类实现得很差，那么您的担忧是相关的。模型类不应该做电子邮件(基础设施任务)。
真正的问题是MVC中的模型意味着什么。它并不局限于只有少量方法的POCO类。MVC中的模型意味着数据和业务逻辑。将其视为经典核心POCO模型的超集。
查看====控制器====模型->业务流程层-->核心模型
加入基础设施、程序集和数据访问层，并使用注入将其交给BPL，那么您的流程就可以按预期使用MVC了。
业务流程许可证可以调用UoW /存储库模式，并通过注入对象或接口模式执行业务规则和调用基础设施功能。
因此，建议保持控制器精简并不意味着经典核心模型中的"person“类应该有50个方法，并直接调用电子邮件。你认为这是错误的，这是正确的。
如果直接调用，控制器可能仍然需要实例化基础架构类并将其注入到BPL或核心层。应该有一个业务层，或者至少是跨Classic对象模型类编排调用的类。这就是我的“观点”;-)
有关MVC的通用观点，请参阅维基描述http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
一个讨论MVC中的"M“的小博客。http://www.thedeveloperday.com/skinny-controllers/
Stack Overflow用户
发布于 2012-12-27 02:54:30
我认为您可以区分单个fat模型(可能名为App或Application)和多个fat模型(分为逻辑组(业务、客户、订单、消息))。后者是我构建应用程序的方式，每个模型大致对应于关系数据库中的数据库表或文档数据库中的集合。这些模型处理创建、更新和操作构成模型的数据的所有方面，无论是与数据库对话还是调用API。控制器只负责少量的调用适当的模型和选择模板。
https://stackoverflow.com/questions/14044681
复制相似问题