互联网上充满了关于什么是真正的MVC的讨论。这个答案是从MVC的CodeIgniter（CI）实现的Angular 。Read the official line here.
正如它在链接页面上所说的“CodeIgniter对MVC有一个相当宽松的方法......"。在我看来，这意味着没有任何真正错误的方法来做事情。也就是说，MVC模式是实现关注点分离（SoC）的一个很好的方法。（定义为here）. CI将允许您遵循MVC模式，同时，正如链接的文档页面所述，“...使你能够以一种对你最有意义的方式工作”
模型不必局限于数据库函数。（如果这对你来说有意义，那就尽一切努力去做吧。）许多CI开发人员将各种“业务逻辑”放在Model中。通常这种逻辑可以很容易地驻留在自定义库中。我经常遇到这样的情况，即“业务逻辑”是如此微不足道，以至于将其放在Controller中是完全有意义的。所以，严格地说，严格地说，其实没有。
在您的情况下，正如其中一条评论所建议的那样，将CSV功能放入库（即服务）中可能是有意义的。这使得它易于在多个地方使用-无论是Controller还是Model。
最后，你希望保持任何给定的代码块与手头的任务相关，并且只与手头的任务相关。希望这可以通过一种保持代码DRY（Don 'tRepeakYourself）的方式来完成。由你来决定如何实现所需的最终结果。

**您需要决定术语Model、View和Controller的含义。

一般来说，MVC之所以流行，是因为它支持关注点分离，这是SOLID编程的核心原则。一般来说（不同的风格支持/推荐不同的实现），你的模型保存你的数据（通常是如何验证或解析的元数据），你的视图呈现你的数据，你的控制器管理你的数据流（这也是通常发生安全和验证的地方）。
在大多数系统中，单一职责原则建议，虽然业务逻辑必须发生在控制器级别，但它不应该实际发生在控制器类中。通常，业务逻辑在服务中完成，通常注入到控制器中。控制器使用来自模型的数据调用服务，获取进入模型（或不同模型）的结果，并调用视图来呈现它。
因此，在回答您的问题时，遵循“最佳实践”（我会将其放在引号中，因为有很多观点，这不是一个非黑即白色的命题），您的控制器不应该处理和解析数据，您的模型也不应该;它应该调用处理和解析数据的服务，然后返回上述调用的结果。
那么，在服务中是否有必要这样做呢？不。考虑到应用程序的大小和复杂性，您可能会发现这样做更合适（即小而不需要定期维护和更新）采取一些捷径，将业务逻辑放入控制器或模型中;这并不是说它不起作用。但是，如果您正在遵循或打算遵循关注点分离和SOLID原则的意图，（对于更大、更复杂的项目，这是个好主意），最好重构它。

回到将项目逻辑分解为模型、业务逻辑和数据访问层的旧概念。
1.模型是代表对象的非常薄的层
1.业务逻辑层用于验证和调用方法以及处理数据
1.数据访问层，用于连接数据库并提供OR关系
在MVC中，以asp.net/tutorials为参考：
1.模型：存储所有对象结构
1.检视：就像一个引擎，显示从控制器发送的数据（您可以将视图视为xml的xsl文件，在本例中是模型）
1.控制器：你调用方法和执行进程的地方。
通常您可以扩展模型来支持验证
最后，在我看来，根据我的经验，大多数敏感的进程，需要一些执行时间，我在sql server端编码，以获得更好的性能，并易于更新的过程中的情况下，如果任何规则被注入或需要一些调整，所有提到的都可以做，而无需重建您的应用程序.
希望我的回答能给你一些提示和帮助

如果你的CSV处理在多个地方使用，你可以使用CI库来存储处理函数。或者你可以创建一个CSV模型来存储处理函数。这取决于你。我最初会在控制器中编写这个代码，然后如果其他地方需要，我会将它分解到库中。
传统上，模型与数据库交互，控制器处理传入的请求，如何处理它，用什么视图来响应。这留下了一层业务逻辑（例如CSV处理），我会把它放在一个库中，但许多人会把它放在自己的模型中。
关于这一点并没有硬性规定。MVC，无论它最初是如何提出的，都是一个在不同环境中有不同解释的松散术语。
就我个人而言，对于CI，我使用瘦控制器，也包含业务逻辑的胖模型，以及处理逻辑（如CSV解析），我会放在一个库中，以便于项目之间的重用。