[davesque]

For most intents and purpose, "controllers" from so called MVC frameworks are referred to as "views" in Django.

The article that edavis mentions does make one good point, which is that the term "view" was chosen to emphasize the notion that the python callback function (or object) sets up a view of the data represented by the models. I think there's something good in this choice of words. I find the terms "view" and "template" more intuitively meaningful than the corresponding "controller" and "view".

One important, substantive difference that I'm aware of between controllers in many MVC frameworks (probably not all) and views in Django is that a lot of MVC frameworks map requests to controller actions through URL traversal, whereas Django offers a more hands-on approach with URL confs.

Also, whereas controllers are often implemented through classes in MVC frameworks, views in Django may be implemented through any callable object which accepts a request and returns a response.

As far as where your code should go, it probably depends on what kind of data the user is entering. If the data must be persisted in the database somehow, such as with transactions in a bank account, then the code that crunches the numbers would probably be in a method on a "BankAccount" or "Transaction" model class. If it's data that only really needs to persist for the user's individual browsing session, then it's probably safe to put the code that works on it in a view. Django limits what kinds of things you can do in its templates (thankfully), so you probably won't have much luck putting your computation code in a template.