I just started learning ASP.NET. I have a project at uni - chess (/w playing algorithm, alpha-beta pruning). I decided to implement it in ASP.NET to learn.
And here is my question: what should the model do, and what should the controller do? The view I guess will be just a template displaying the chess pieces and some info.
I saw one guy's app where he put almost all logic into Controller. Shouldn't game logic go to the Model? I believe that the app runs like:
So... how would you go about implementing a game of chess in ASP.NET MVC 4/4.5?
As @usr suggested, the reason behind MVC is to separate the presentation layer from the business logic layer (in order to improve testability, maintainability, etc.).
In your case (as in all software projects) it really depends on the time and effort you want to put into your solution.
If you want to create something quickly or prototype an idea, then go ahead and put all the logic into the Controllers, you will be quick and prove that your code works, at least.
When the project grows or require maintenance, you will realise that this approach causes more pain than it gives benefits: the code is scattered and the logic is sparse. The next step then, requiring a little more effort, is to distil or refactor the knowledge from the Controllers into a set of classes (the domain model) responsible for the game of chess in general.
This way you achieve one important goal: enclosing the whole logic of your project into a manageable, maintainable, and reusable library, maybe surrounded by intention-revealing interfaces which specify the API available to the main project.
This main project can then be a desktop app, a mobile app, a MVC app, whatever you think of it: a thin client around a fully functional and robust core.
You will have to face some decision in this design: for example the classes in the core will generally be different from the models in the MVC app (which tend to be POCO objects in general, although they don't have to); so you will have to decide if you want to go for an adaptor that can map between the two or go for the simpler solution of using the classes in the core as Models in your MVC.
Another problem will probably be the decision on how to manage persistence (saving to the DB).
A thing to not forget, absolutely, is a nice set of tests around your core API: they will define and document its behaviour and will prove an invaluable help during refactoring.