到目前为止，在我的MVC应用程序中，我一直在使用模型主要只是为了访问数据库，而其他很少。我一直把控制器视为操作的真正大脑。但我不确定我是否正确使用MVC模型。
例如，假设有一个金融交易数据库（订单号，订单商品，金额，客户信息等）。现在，假设有一个函数来处理.csv文件，并将其作为数组返回，以插入到事务数据库中。
我将我的.csv解析函数放在我的Controller中，然后控制器将解析后的信息传递给要插入的Model中的函数。但是，严格地说，应该将.csv解析函数包含在模型中吗？
编辑：为了清楚起见，我特意使用的是CodeIgniter，但问题确实与MVC结构有关。
答案 0 :(得分：2)
互联网上充斥着关于什么是 true MVC的讨论。这个答案来自MVC的CodeIgniter（CI）实现。 Read the official line here.
正如在链接页面上所说的那样#CodeIgniter对MVC有一种相当松散的方法......＆＃34;。其中，IMO，意味着没有任何真正错误的做事方式。也就是说，MVC模式是实现关注点分离（SoC）（定义{{3}}）的一种非常好的方法。 CI将允许您遵循MVC模式，而链接文档页面说明，＆＃34; ...使您能够以对您最有意义的方式工作。＆＃34;
模型不必限于数据库功能。 （虽然如果这对你有意义，那么无论如何都要这样做。）许多CI开发人员提出了各种各样的商业逻辑＆＃34;在模型中。通常，这种逻辑可以很容易地驻留在自定义库中。我经常遇到这样的情况，即商业逻辑＆＃34;是如此微不足道，让它在控制器中完全有意义。因此，严格地说 - 严格来说，确实没有。
在您的情况下，正如其中一条评论所暗示的那样，将CSV功能放入库（a.k.a。服务）可能是有意义的。这使得它易于在多个地方使用 - 无论是控制器还是模型。
最终，您希望将任何给定的代码块保持与手头的任务相关，并且仅与之相关。希望这可以通过保持代码DRY（ D on
您决定模型，视图和控制器的含义。
答案 1 :(得分：1)
作为一般规则，MVC很受欢迎，因为它支持关注点分离，这是SOLID编程的核心原则。一般来说（不同的口味支持/推荐不同的实现），您的模型保存您的数据（通常是元数据，如何验证或解析），您的视图呈现您的数据，您的控制器管理您的数据流（这通常也是安全和验证发生）。
在大多数系统中，单一责任原则会建议虽然业务逻辑必须在控制器级别进行，但它实际上不应该出现在控制器类中。通常，业务逻辑在服务中完成，通常注入控制器。控制器使用模型中的数据调用服务，获取进入模型（或不同模型）的结果，并调用视图进行渲染。
所以回答你的问题，遵循＆＃34;最佳实践＆＃34; （而且我会把它放在引号中，因为那里有很多意见并且它不是黑白命题），你的控制器应该不进行处理解析数据，你的模型也不应该;它应该调用处理和解析数据的服务，然后返回上述调用的结果。
现在......有必要在服务中这样做吗？不会。考虑到应用程序的大小和复杂性（即小而且不需要定期维护和更新），您可能会发现它更合适，可以采取一些快捷方式并将业务逻辑放入控制器或模型中;它不喜欢它不会工作。但是，如果您遵循或打算遵循分离关注和SOLID原则的意图（并且它对更大，更复杂的项目更好），那么最好重构一下。
答案 2 :(得分：0)
回到将项目逻辑分解为模型和业务逻辑以及数据访问层的旧概念。
，并以asp.net/tutorials为参考：
通常您可以扩展模型以支持验证
最后，在我看来，根据我的经验，大多数需要一些执行时间的敏感进程，我在sql服务器端编写代码以获得更好的性能，并且如果注入了任何规则，则很容易更新程序或者需要进行一些调整，所有提到的都可以在不重建申请的情况下完成。
我希望我的回答能给你一些提示并帮助你
答案 3 :(得分：0)
如果您的CSV处理在多个地方使用，您可以使用CI库来存储处理功能。或者，您可以创建CSV模型来存储处理功能。那取决于你。我最初会在控制器中对此进行编码，然后如果需要在其他地方再次编写，那就是我将其分解到库中。
传统上，模型与数据库交互，控制器处理传入请求，如何处理它，响应什么视图。这留下了一层业务逻辑（例如你的CSV处理），我将它放在一个库中，但许多人会把它放在自己的模型中。
对此没有严格的规定。然而，最初提出的MVC是一个松散的术语，在不同的环境中有不同的解释。
就个人而言，使用CI，我使用瘦控制器，也包含业务逻辑的胖模型，以及像CSV解析这样的处理逻辑，我会放入库中，以便于项目之间的重用。