When I saw a new item in my RSS feed from Rob Conery about MV* I was immediately interested to read it, because I have been working on trying to create my web app pages using MVP, but am unable to find any examples beyond the most basic.
I would love to see how other people manage the interactions between the Controller and the View, to see how it compares to how I am doing it.
My view interfaces tend to be kinda large. For example, if I have a button that I hide and show depending on business rules, I will create a MyButtonVisibility property on the interface can set the properties from the controller.
I would be interested to see how others deal with things like the hiding / showing of items. I could see wrapping more of that kind of functionality in the view, and giving the view some more logic but I think you would then start to lose some of the testability.
Anyway, the articl on Rob’s blog was really to talk about creating an MVC style architecture for subsonic itself, not the pages that use it. However, Rob seemed to suggest that the new changes would aid you in using MV* in your pages by forcing you into good habits.
But I really don’t understand how that would work. If you have code that does:
MyGridView.DataSource=Product.FetchAll();
MyGridView.DataBind();
And you change it so that you use a Controller (or Manager as I have called it when loading Business Objects or DTOs) to look like this:
Product product = ProductController.Get(newID);
product.ReorderLevel = 100;
ProductController.Save(product,"unit test");
I don’t see how this helps you create an MV* architecture in your pages.
Maybe I am just not understanding.
Chris May 
It boils down to how "smart" you want your objects to be. If an object can load and persist itself, it can push you to sidetrack your existing MVC pattern by having an object load a control (or worse yet save itself) in page-behind code.
So, if you were forced to route all calls through a controller, then you’re forcing everything through a central logic point correct?
Take the last example there – you can override the "get" routine to do all kinds of nice things like logging, loading child collections, etc. It’s more preferable to run these loadss through a central logic point that’s NOT your model object.
Rob,
First, thanks for noticing my post, and for replying.
I understand the idea of removing some logic out of the object and putting it in another class (controller). I have done this type of thing before on projects basically as a seperation of concerns item. Basically answering the question "Does the object really need to know how to interact with the database?" with "No" and building another class whos job it is to create/persist objects and collections.
Where I am not tracking is how this applies to the MV* architecture of a webform. I mean, you could *self impose* a "rule" that you will only use the ProductController in the "Controller" of your webform and your "View" will only contain references to the Product, not the ProductController (therefor you will need the webform controller to save the product). But couldn’t you just as easily accidentally "mess up" by putting the ProductController.Save(product); code in the click event handler for a button, just like you could do Product.Save() in the same place?
Or, is the "ProductController" a PAGE/Webform Controller as well?
I was thinking it was just in control of creating/persisting the objects/collections. If it is also given business logic to drive the webform, then that is where I had the disconnect.
Again, thanks for the reply.