Which of these parts goes into the model vs. controller?

I have 5 tasks that a step of my application needs to perform.

1. Receive a CSV file as part of a user upload.
2. Parse each row in the CSV to a canonical representation.
3. Create an ORM POCO relating to that representation.
4. Save each item to the database.
5. Send an email to an email address defined in each POCO.

I have a repository already for the database ORM s开发者_开发知识库tuff, and I've at least got it figured out that the controller probably shouldn't be new'ing up an SmtpClient by itself, but how much 'glue' goes into the controller? Is exposing any more details than my snippet below a code smell?

public ActionResult Index(HttpPostedFileBase file) {

    var result = model.HandleFileUpload (file);

    if (result.Success) 
    {
        return SuccessAction("Success");
    } else {
        return FailureAction("Failure");
    }

}

If this does all belong in the model, what's the type of work I'm doing called, if I'm just "gluing" lower-level things together?

---

The thin controller you describe looks pretty good to me. It's easily testable, and makes it easy for you to adhere to Single Responsibility Principle by creating a set of loosely-coupled service classes in your model, each of which handle a different step of your process. This also allows you to make use of the code outside of the confines of your MVC application, should the need arise.

So, I would envisage you having a FileHandler class implementing your HandleFileUpload method. This would define the steps of the process, perhaps calling out to FileParser, Repository, and EmailSender classes, each of which could be consumed via interfaces and dependency-injected into your FileHandler.

What's the type of work you're doing? Developing maintainable software of which you can be proud :-)