I've read the Head First Design Patterns book MVC pattern section several times in an effort to understand MVC. I finally have a project that can really implement it (most of the time I'm doing web app development and find it difficult to apply the MVC pattern to ASP.NET - yes I realize there is now an MVC framework for it, that's another discussion).
I am starting to understand the implementation and now have what I believe is a clear separation of what the model, view and controller should do. However, as I've been developing I've come across this question:
Where should I put logic that is really about user interaction?
For example, I have a view that shows the data of the model. On the view is an action trigger for the "AddThing" action. The view is the first to handle the action request, and in MVC fashion, hands off the request to the controller which actually does it. Part of doing this action is to prompt the user for the new thing that will be added. This requires showing a dialog to prompt for the new thing's information.
Where/how do I handle this?
I'm my case, I have an assembly containing all the presentation entities (windows forms and user controls) as well as an implementation of the controller. I'm thinking that this implementation is the "windows forms presentation controller" version of the controller so it's reasonable that it knows about the available forms in order to actually execute the action requests. After it prompts the user for the new thing's information, it delegates the action of actually adding the thing to the model off to the model instance. So the business logic of the model is in the model, while some of the user interface logic is in the concrete controller implementation. The logic specific to how the view actually displays the model is still in the view itself.
When I port this application over to the web, I'll create another concrete controller implementation (in the web app) which will know about the various pages and such in order to provide the right behavior there. There will also be new views, but the main model will remain the same.
Am I implementing MVC correctly? Should the user interface logic (not that of the view however) be abstracted out even further in some way?