jrnail23:

Any way a strongly typed contract could be applied between view posts & the receiving controller action would go a long way toward soothing my team's anxieties toward ASP.NET MVC.

...

If this sort of thing doesn't make its way into the MVC framework, does anyone have any ideas as to how we might implement it ourselves (or maybe in MvcContrib)?

Just kind of off the cuff... it seems to me you would have data objects that define your Model and contain their own validation logic. When you get a POST the controller instantiates the appropriate objects, fills them from the POST data (nice helper method exists for this) and then asks the object if it is valid or not. If not, the controller knows to push back to the user with some error or missing field or whatever. If it is valid, it knows to proceed with telling the model to do what it does best. I don't see how defining hard points with interfaces and configurations will make this any more solid. It seems very simple and elegant to say Model, here's your incoming data, are you valid or not?

Model = Business Logic
Controller = Application Logic
View = (Lean & Mean) Presentation Logic

 

What it would do is to allow me to catch a programming error at design/compile time.  We're not talking about validating business logic here, we're talking about the structural integrity of our application code.

>> Model = Business Logic

This is key! I get the feeling that some folks are getting tripped up by the term Model and confusing it with with the term Domain Object (sometimes called an Entity or even domain Model).

These domain objects are often implemented as a POCO or possibly something a bit smarter, like an ActiveRecord object. They are used to represent the resources w/in the problem domain (things like Person, User, Product, Payment, etc...) and are operated on by the business logic. They are also often passed around between various layers of your application, like between the business and service layers.

The term Model, as we're using it when talking about MVC, is basically EVERYTHING that encapsulates the business logic. So your domain objects, services, etc... all might be considered part of the Model in the general sense. However, each of these various pieces of the Model may live at different layers - services layer, business logic layer, data store layer, etc...

Does that track or did I just talk myself into a hole? :)
 

Were you responding to the discussion of view interfaces?

jrnail23:

...

But the problem we have with the current implementation of ASP.NET MVC is first, that there's no strongly-typed interaction between the View and the Controller when posting to the Controller.

I would submit that this is the crux of your issue, and comes from a misunderstanding of how the web and MVC entry-points work. Since *anybody* can request any given action on any given controller (just by knowing the appropriate request to make of the web server) it doesn't make much sense to me to try to strongly type this interaction. This interaction goes through a completely abstracted (from your application) code path -- not to mention physical path as it travels over the wire from a disconnected client every time.

Also, there are two main "flows" that are in play here. To specify view interfaces has to do with outgoing flow. The controller would need to know what view types (interfaces) it is allowed to call Render on. The opposite flow path would require controller interfaces, and the views could only call actions on the controllers that view has been made aware of. (This constitutes tight coupling, IMO.)

Since this just isn't the way web requests work, I'm not sure what you would gain by typing this stuff and what you would expect the compiler to be able to offer you.

I believe this is completely covered by the unit testing of your application logic, in that controller actions *can* be called from anywhere, and therefore it's part of robust logic (and testing) to ensure the controller can handle invalid requests. If you strongly type this, you'll likely leave that kind of checking out of your code, and your testing, and therefore leave your controllers vulnerable to invalid requests that don't originate in your interface-aware views.
 

jrnail23:

Any way a strongly typed contract could be applied between view posts & the receiving controller action would go a long way toward soothing my team's anxieties toward ASP.NET MVC.  If something like this were to find its way into the MVC framework, I'd expect it to be optional, perhaps using optional attributes, or even a config value. 

 

 Hmmmmm, so say you have a partial view called "LoginBox" which contains a textbox for username and for password. You'd like to

1) be able to re-use that partial view on different pages, similar to a UserControl or ServerControl in WebForms.

2) Ensure that the controllers for those pages must have an action for handling the LoginBox "submit" event.

 
If that's correct, it should be pretty easy to do by creating an interface (IHandleLogin) with a method defined as an action (handleLogin). Which seems testable. But I'm a little confused as to why you'd need any kind of tie-in between the view and the controller other than the obvious one that exists due to their relationship to each other. Is it the fear that someone might include the partial view on a view and not implement the proper action on the associated controller? You want to catch that at compile time rather than raise an "action not found" error at runtime?

My thinking was more along the lines of having the partial view have it's own separate controller. So the main view could be composed entirely of partial views, each with their own controller. Which would do away with the need to create any kind of contract between the main view and it's controller. Maybe defining a controller property for the partial view? It sounds kind of code-behindish, but I don't think it is code-behind and it would still maintain the MVC pattern.

sliderhouserules:

If it is valid, it knows to proceed with telling the model to do what it does best. I don't see how defining hard points with interfaces and configurations will make this any more solid.

Hey, no fair, that's exactly what I said earlier :)

I think I see what he's going for, as compile time check which is what strongly-typed languages give you though having to code in enough dynamic languages like Rails & JavaScript I've learned to trust my tests more than the compiler.

What's the root issue, is it that you're looking for a way to ensure that for every Model field your View has a matching input?  If you just want to make sure a POST or GET, regardless of origin, always sends a certain number of form fields before hitting an end-point then the best solution is a unit test that parses the POST parameters and ensures it matches your requirements.  You might not catch a missing field at compile time but since you should be running your tests after every compile you'd catch it about a minute later. 

How did you solve this with WebForms?  Seems you'd run into the exact same issues or that you could apply some of the same solutions.

After reading lazycoder's response (and the quote he answers) I think I understand a bit better what you're getting at jrnail23. You want a data contract, similar to what web services offer. Or in other words, you want verification that the POST data conforms to some pre-defined contract... am I getting that right?

I don't think this is a bad idea, when I look at it this way. They've already provided the helper method UpdateFrom... this could just be moved into an attribute form that allows a data class to be specified and if the POST data doesn't conform to this then it's "bad". 

ShawnOster:

sliderhouserules:

If it is valid, it knows to proceed with telling the model to do what it does best. I don't see how defining hard points with interfaces and configurations will make this any more solid.

Hey, no fair, that's exactly what I said earlier :)

My best ideas are simply regurgitations .

sliderhouserules:

... this could just be moved into an attribute form that allows a data class to be specified and if the POST data doesn't conform to this then it's "bad". 

I actually still don't know how you could catch this kind of mismatch at compile time. As mentioned above, this isn't a deviation from WebForms or the general HTTP client/web server interaction overall.