Quick December 2010 Update

by Jon Davis 27. December 2010 06:20

I hope everyone had a great Christmas. I just thought I should post a quick note indicating what I’ve been up to lately.

Among other things I am back in independent consulting and subcontracting for software and web development. I enjoyed my previous job and I feel I did my team good—I know the team did me good!—but it was an obvious no-brainer to move on when I did (this was back in September/October), everything fell into place perfectly and it was a satisfying transition on all sides when I resigned. So far I think it was the best decision of my life. I am more naturally a consultant than a yes-man grunt, and yet I am a night owl and see no practical reason to keep myself from doing what I do best at the hours I am most productive—which can sometimes be in the middle of the night on my sofa with my laptop! (That said, I got way less done this Christmas weekend than I planned. Oops.)

Current technical areas of interest and/or focus lately are:

  • Lucene.net – Yeah I’m looking at it again, and from what I understand it’s currently undergoing a “come-to-Jesus” situation with Apache Foundation. One or more of the forks  [1, 2] may end up taking its place as the better Lucene implementation for .NET. But it’s still bread-and-butter for high performance text-based indexing / textual entity matching / content searching.
  • nopCommerce – This particular e-commerce project has been good at staying up-to-date with modern technical standards. Although it gets some heat for being heavily refactored frequently, the advantage is that you can pick this thing up and know that you’re using a modern codebase—currently Entity Framework and ASP.NET Web Forms 4.0, soon to be refactored into ASP.NET MVC 3.0. I’d definitely prefer that over some old codebase that only fixed bugs after v1.0 rather than constantly evolve to modern standards; this is where I begin to disagree with some whiners about .NET who migrate to open source, I see nothing wrong with rewriting an old codebase to something more modern, so long as the people who experienced the pains of lessons learned are still around to reimplement.
  • Orchard Project – As WordPress has grown exponentially in popularity over the last year, I had been seriously considering creating a .NET equivalent of WordPress (core plus extensibility), but Orchard Project meets this goal of WordPress core-plus-extensibility equivalence and pretty much every requirement I wanted to pursue in my own implementation, including the new Razor view engine for ASP.NET MVC 3.0. I have every intention of delving deep into this project’s codebase.
    • I also took the initiative and registered an IRC chat channel for Orchard—#orchard on Freenode, find me as stimpy77—a channel had been asked for but not created and after months went by I decided to just register the channel myself.
    • Finally, I’m going to present a session on this project in March at a local .NET user group in Chandler.
  • Facebook – In case you’ve been living under a rock, Facebook is the most popular web site on the planet at the moment. If Google’s data was social network data, they’d be Facebook. It’s that big. Facebook also has a lot of integration points. The SDK I’m using at the moment is the one at http://facebooksdk.codeplex.com/. This as opposed to the Facebook Developer Toolkit (http://facebooktoolkit.codeplex.com/). Facebook SDK rather takes advantage of C# 4.0’s dynamic keyword so that the maintainers of the SDK don’t have to have a one-to-one property mapping for every entity documented; Facebook’s API changes far too often to be able to keep up with these changes reliably, so the SDK relies on simple deserialized JSON as dynamic object graphs that can be accessed with minimal code. For me as a .NET developer, it kind of makes haughty dynamic languages’ implementations of Facebook APIs look rather irrelevant.

I’d love to add a lot more to the list but the fact is that I, like many others in the .NET community, have been really quite overwhelmed by all the goings on in 2010 what with Windows 7, Visual Studio 2010, ASP.NET MVC 2.0 and now 3.0, and so on, and have been glad I’ve been able to keep up as far as I have. I still have a ton of catching up to do, though.

Cheers to the New Year 2011!

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags:

Testing Basic ASP.NET MVC View Model Validation With Brevity

by Jon Davis 1. December 2010 21:55

(Note: “Brevity” is not a proper noun. LOL .. sounds like it would make a great library name though doesn’t it?)

I recently attended a Desert Code Camp session that introduced attendees to Rails (as in, Ruby on Rails). I’d gone through similar introductions before, but I needed a refresher and another perspective from another mouthpiece. I was reminded yet again that the bulk of the power of this thingamajig, Rails, is plain vanilla code generation. There is no shortage of code generators in the .NET world, and it is nothing new (tools like MyGenerationSoftware, CodeSmith, T4, et al, have been around for years) but the problem with code generators is that you have to go back to the code generator if you need to adapt and refactor as business requirements evolve and knowledge and understanding increase (or as sanity wanes while workarounds perpetuate, omg).

One feature of Rails stuck out at me again, however, and that is RoR’s approach to TDD in model validation. In the session, the speaker cobbled together a simple unit test, threw some one-liner validation rules into the model, “rebuilt” the app, and watched the red/green output spit out immediately upon build. Once the validation rules were properly applied to the model, this immediately showed up in the web view scaffolding. This is exactly the way all development should be—some Ruby enthusiasts believe that unit tests deprecate the applicability for strongly typed language compilation altogether, I think that’s ridiculous, but I love the idea of supplementing compilation with post-build unit tests as a standard practice, not to mention combining the fundamental object metadata with the behavior of core view functionality in any UI framework.

I looked again at ASP.NET MVC and, having done rather little with the supposedly great testability of the ASP.NET MVC platform, had to figure out how to apply what I had just seen in this RoR session to the ASP.NET MVC platform scenario. I already knew that ASP.NET MVC supports easy peasy validation metadata out of the box, using the System.ComponentModel.DataAnnotations namespace and the attributes therein to decorate the properties of my view models. Notice the [Required] and [RegularExpression] attributes in the stupid sample below:

using System.ComponentModel.DataAnnotations;

namespace MvcApplication2.Models
{
    public class Fiz
    {
        [Required]
        public string Name { get; set; }

        [Required]
        [RegularExpression(".+@..+")]
        public string Email { get; set; }
    }
}
The problem, however, was that I was still green on how to actually validate that applying the ASP.NET MVC built-in validation functionality to an instance of this model actually works in a non-UI unit test. For example, let’s say I had not yet added the [Required] attributes in the above code yet, and, using red/green TDD coding practices, I first create a unit test and execute this test (seeing red, or “Fail”) before applying the validation rule. What would such a unit test look like?

That is actually the main purpose of this blog post, if for no other reason than to have it for my own reference. ;)

The first example I came across explained that one would need to actually have the controller for this model in place, and an appropriate action, such as Create(), to capture the model. This controller would then be able to expose the ModelState property which would be able to return a property indicating IsValid.

// unit test code, but don't use this
[TestMethod]
public void TestMyModel() {
    var fizController = new FizController();
    var unusedActionResult = fizController.Create(fiz);
    Assert.IsFalse(fizController.ModelState.IsValid); // doesn't even work anyway without bringing out the Validator
}
The author of this example continued on to explain how to invoke the validator to fill in the missing functionality.

// My own flavor, does not require explicit controller.
// Still, don't use. Not where we want to be yet.

private class ValidationController<T> : Controller
{
    public T Model { get; set; }
}

private Controller BindModelValidation<T>(T model)
{
    var controller = new ValidationController<T>();
    var validationContext = new ValidationContext(model, null, null);
    var validationResults = new List<ValidationResult>();
    Validator.TryValidateObject(model, validationContext, validationResults);
    foreach (var validationResult in validationResults)
    {
        controller.ModelState.AddModelError(validationResult.MemberNames.First(), validationResult.ErrorMessage);
    }
    controller.Model = model;
    return controller;
}

[TestMethod]
public void TestMyModel() {
    var fiz = new Fiz();
    var validationController = BindModelValidation(fiz);
    Assert.IsFalse(validationController.ModelState.IsValid);
}
And that’s fine, except for the fact that the separation of concerns (model vs. controller) is instantly lost; except where custom validation behavior is declared on an overriding controller there’s really no reason to even look at controller logic here. What we want to test is the model’s validation metadata and behavior in the context of ASP.NET MVC’s existing plumbing, nothing more, since we already trust that Microsoft already QA’d ASP.NET MVC and its controller and validator classes.

Fortunately, inspecting this code it seems Microsoft did provide a Validator class with static methods exposed to validate a model based on its metadata. You don’t need to involve a controller at all. If you look closely, Validator.TryValidateObject(..), while being stupid in that you have to pass in a context object (even if you’re gonna instantiate a new throwaway one anyway), will return a list of validation failures, or ValidationResults. So why don’t we just validate the validation by validating that the count of validation failures is not zero?

// Final code, I'm happy with this. Just need to move the
// helper method ValidateModel() to a base class or
// somewhere else that's clean and out of the way and
// won't be copied/pasted.
[TestMethod]
public void EmailRequired()
{
    var fiz = new Fiz 
        {
            Name = "asdf",
            Email = null
        };
    Assert.IsTrue(ValidateModel(fiz).Count > 0);
}

private IList<ValidationResult> ValidateModel(object model)
{
    var validationResults = new List<ValidationResult>();
    var ctx = new ValidationContext(model, null, null);
    Validator.TryValidateObject(model, ctx, validationResults, true);
    return validationResults;
}
Any reason why this won’t work? Any reason why Microsoft made brevity for validating model validation such an effort to be had?

Currently rated 4.5 by 2 people

  • Currently 4.5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags:


 

Powered by BlogEngine.NET 1.4.5.0
Theme by Mads Kristensen

About the author

Jon Davis (aka "stimpy77") has been a programmer, developer, and consultant for web and Windows software solutions professionally since 1997, with experience ranging from OS and hardware support to DHTML programming to IIS/ASP web apps to Java network programming to Visual Basic applications to C# desktop apps.
 
Software in all forms is also his sole hobby, whether playing PC games or tinkering with programming them. "I was playing Defender on the Commodore 64," he reminisces, "when I decided at the age of 12 or so that I want to be a computer programmer when I grow up."

Jon was previously employed as a senior .NET developer at a very well-known Internet services company whom you're more likely than not to have directly done business with. However, this blog and all of jondavis.net have no affiliation with, and are not representative of, his former employer in any way.

Contact Me 


Tag cloud

Calendar

<<  September 2018  >>
MoTuWeThFrSaSu
272829303112
3456789
10111213141516
17181920212223
24252627282930
1234567

View posts in large calendar