Nov 20, 2013 Posted by John MacIntyre

How to keep your Get & Post ViewModels DRY

I’ve been convinced that I should not be using the same view model class for both loading the view and the posted controller action parameter. The trouble is it allows data to be transferred back which may not be necessary and it needlessly increases our attack surface. Don’t get me wrong, I’ve always had unit tests specifically monitoring that only necessary view model properties are being pushed back to the entity model, but still, seperate viewmodels will allow me to eliminate that risk completely and even remove those tests. To be honest, the idea of having 2 view model classes that are nearly identical is not very appealing, especially given that if the structure deviates, the default model binder will no longer work with those properties which are out of sync with its partner view model. Don’t get me wrong, I’m very liberal when it comes to class quantities, but this was enough to make me uncomfortable. So I’m happy that I realized the post view model class can always be used as a base class for the get view model class. I mean it has to be in order for the default model binder to work. Using inheritance for these classes will a) keep these classes in sync so the default model binder will always work, b) follow the DRY principle and c) keep my sanity. In a nutshell, rather than having 1 2 3 4 5 6 7 public class FooViewModel { public int Id { get; set; } public string Name { get; set; } public FooStatusEnum Status { get; set; } public DateTime CreateDate { get; set; } }public class FooViewModel { public int Id { get; set; } public string Name { get; set; } public FooStatusEnum Status { get; set; } public DateTime CreateDate { get; set; } } We can instead have 1 2 3 4 5 6 7 8 9 10 11 public class FooPostViewModel { public int Id { get; set; } public string Name { get; set; } }   public class FooGetViewModel : FooPostViewModel { public FooStatusEnum Status { get; set; } public DateTime CreateDate { get; set; } }public class FooPostViewModel { public int Id { get; set; } public string Name { get; set; } } public class FooGetViewModel : FooPostViewModel { public FooStatusEnum Status { get; set; } public DateTime CreateDate { get; set; } } So FooGetViewModel is loaded and passed into the view.... read more

Jul 9, 2012 Posted by John MacIntyre

The asp.net-mvc predicate

I have a theory that you can tell if a Microsoft web developer is good or not based on as single question. Would you choose webforms or MVC on a new project? Many readers probably consider this obvious, perhaps even equivalent to the choice between punch cards vs keyboard/monitor. I suspect most people reading this consider asp.net-MVC the logical choice, and only an idiot would choose otherwise However, I suspect most Microsoft web application developers would still chose webforms … scary as that is. I think that right now, MVC has really separated the good from the bad, at least as far as asp.net developers go. Developers on top of their game have at least overview experience with MVC, yet most weak or lazy developers haven’t been forced to make the leap yet, as a result they either haven’t looked into it, or have been so confounded by the paradigm shift that they’ve passed it off as a trendy fad. Please notice I said ‘choose on a new project’, not ‘currently working in’. I’m sure there are many developers who are working in webforms who would prefer to be working in MVC … I’m one of them. On the flip side, I recently met a developer working in an MVC app who wishes it was webforms. There is a presumption in my statement, that MVC is inherently better than webforms. To most of us, this seems obvious, but there are many who disagree … and that’s fine. However, I’ve yet to find a valid argument for webforms over MVC. … don’t get me wrong, I’ve heard people tell me that webforms is better, but I’ve never heard a rational argument. Those who have tried have basically given me buzzwords like ‘event-driven’ but fail to contrast it against, or even recognize the cost of that paradigm. Take for example; answers to this Stackoverflow question When to favor webforms over MVC? I’m not going to argue about integrating MVC into an existing webforms app because I think maintaining technology consistency is important. But some of the other reasons include : Leveraging existing training – True, but good developers usually keep their skills up to date, so is this really that big of a deal? View/edit modes makes duplicate work – This is actually better than all edit pages, yes … even for enterprise apps. If you don’t believe me, just think about all the functionality you added to ensure users couldn’t ‘save’... read more

Nov 7, 2009 Posted by John MacIntyre

How to hook up NUnit as an option in the ASP.NET MVC application wizard

Ben Alabaster and I have started a project, lets call it Project X for now (original eh? ;-). Anyway, we have decided to blog about its development. I will be posting something in the next few days, and Ben just published his first post “How do I hook my version of nUnit into the ASP.NET MVC template?“. Here’s a blurb: If you’ve been looking for a way to integrate nUnit into your ASP.NET MVC 1.0 template – that is, when you create a new ASP.NET MVC application and it asks you if you’d like to create a test project, nUnit shows up in the list along with the usual Visual Studio Unit Test option. There are a number of longwinded ways of doing things. There’s also a relatively simple way touted on the Visual Web Developer Team Blog which I’ll spare you the headache of running it and finding the same problems I did…. Ben’s post can be found on his blog... read more