John V. Petersen

Should be a great event! Hope to see you there.

As in, all blog posts germane to the discussion and debate are REQUIRED…

As the famous Philadelphia Mayor Frank Rizzo said – don’t write a letter. And, if you get one, don’t throw it away.

I’d like to tell you that I invoked a clever mechanism to revive Brad Wilson’s [Required] Doesn’t Mean What You Think It Does blog post.
But alas…I cannot.

To be candid, I simply forgot… On another PC, I forgot to close the browser that had the post in the window. So in that regard, I simply took the post, as it was rendered from the site and saved the content, as it was rendered from the site. You can find the original content here.

Since then, Brad made a new blog post – Input validation vs. Model Validation in ASP .NET, or as I like to call it – reframing the discussion to suit the intent of your original premise, while at the same time, ignoring the fact that a previous discussion occurred.

I’m sure Brad is a good guy. Still, when people take the time to make blog posts AND to post comments, that effort should be respected. Taking down the blog post and comments (comments have since been re-added) demonstrates a level of contempt and disrespect to the community. If you write a blog post that contains opinion and you invite comment and scrutiny from the community , then stand by it. And when necessary, concede the point that perhaps, in this case, you simply got it wrong and/or the points raised by others are valid. Anything else and you are simply disregarding input from that same community. None of this is to say that the community always gets it right. The criticisms here have more to do with the process than the substance of the matter.

Nothing gets me going like cases when a technically indefensible position is supported with unsound arguments. Recently, Steve Mason wrote on his blog about how ASP MVC 2 is broken. Long story short, even if you specify that certain data is required, if you omit the field in your view, validation on that element will not occur. The reason is simple – if you omit a field in the view, there will not be a corresponding item in the forms collection. Since no forms collection item exists, there is nothing to validate against. As it turns out, this has actually been a problem since ASP MVC 1.0. The difference is, with ASP MVC 2.0, an attribute-based approach has been introduced. Steve does a nice job of pointing out the problems. In very short order, Steve tee’s up the issue and supports the assertion in a very sound way.

From my perspective, this is a slam dunk issue. We MODEL business problems. We write business rules against a MODEL. The new ASP MVC 2.0 feature allows us to decorate members of the MODEL. Clearly, I am emphasizing the world model for a reason. It’s the one constant we have in our application. Views, depending on context, can have varying content. What is/is not in a view is not nearly as important as what the model and its associated rules dictate. From a separation of concerns (SoC) stand point, the model should not be affected by what is/is not in the view. As Steve points out, in spite of specifying in the MODEL that a field is required, if the corresponding field is not in the view, the required attribute will be ignored. Given this side effect, it would appear there is a serious SoC problem in ASP MVC. A model is the last line of defense. When we attempt to save data against the model, regardless of where it comes from, the model needs to be the entity that specifies whether data is in a valid state.

Steve posted these findings on 1/19/2010. The next day, Brad Wilson, an ASP MVC team member, provided a rebuttal in his post: [Required] Doesn’t Mean What You Think It Does. There are many comments to this post, including a few of my own. The universal viewpoint is that the team got this one wrong. For me, what really escalated this was the basis Brad used to support his argument. Essentially, Brad’s argument relies on a new and novel definition of the word Required. He attempts to use a contextual argument. The problem with that argument is that it uses an invalid context. In the MVC space, when it comes to data integrity and validity, the MODEL is the only context that matters. What’s worse is that Brad then states, as a per se rule, that we should never bind to our ORM objects (MODELS). That of course, is total nonsense. As Rob Conery pointed out, every example, including Nerd Dinner, binds to ORM Objects. In one sentence, Brad indicted every MS ASP MVC example. Instead, Brad argued that there needs to be a layer of abstraction that buffers the model. Three points. One – Brad offers no basis to support that argument and Two – that is not in keeping with the MVC pattern. Third, even if you had an additional abstraction, the core problem would still exist. At some point, you need to deal with the model. I for one do not see the value proposition in another abstraction layer. Additional layers tend to lead to overly engineered/complex systems – without much value in return. Brad also threw out some nugget about how validation is not a security feature. That was a complete non-sequitur. Nobody is arguing that it is. As far as I am concerned, that is nothing more than putting up a strawman to advance what is already a flawed argument.

To take the illustration further, I went ahead and ran this scenario through Nerd Dinner on Rails. As some of you may know, as a learning exercise, I rewrote the ASP MVC Nerd Dinner app in Ruby on Rails. In Rails, if you want to validate the presence of a field, you use the validates_presence_of class method:

class Dinner < ActiveRecord::Base
   has_many :Rsvp, :dependent => :destroy
   validates_presence_of :Eventdate,:title,:description,:contactphone, :address

When I removed the event date from the view and attempted to save a dinner it didn’t save. Instead, I was greeted with the expected result:

In other words, event date is required….. Of course, this is only part of the story. Just because a date is specified, it may not be correct. For example, a past date, while present, is nevertheless, invalid. The key is, model validation in Rails is not dependent on what is/is not in the view. This is what ASP MVC strives to emulate and this is how the feature should work. That should be the focus. The focus should not be on some after-the-fact rationalization that does not hold water.

On the next day, there was this gem of a post : Steaks and stones: a parable. Note the link at the bottom of the post. Lots of good comments here to.

Bottom line, words have meaning and we shouldn’t be attempting to re-define words to suit a set of unfriendly facts. I think the ASP MVC team has done good work. I think that team represents something I would like to see more of in Microsoft. That said, my plea is simple – spend less time with posts like Brad’s and more time fixing problems that are clear and have been brought to its attention. Posts like Brads are the very thing that damages credibility, and in the process, illustrates why very often, MS criticisms are valid. If arguments and justifcations are going to be advanced, they have to be defensible and intellectually honest. In the event they do not pass peer review and scrutiny, the prudent course of action is to acknowledge that fact and go back to the drawing board.

The good news is that it appears we have been heard. Check out Phil Haack’s comment.