I haven’t made a New Year’s Resolution in many years. My last one was to never again make a New Year’s Resolution. I am holding to that by creating an Early Resolution (TM) – well, several. This is more to give me goals to strive for within 2010 but also to keep myself acknowledged on my achievements so I can reflect, see what I did, and set the following year’s goals. I have already posted a few on Twitter, but wanted to put this out there as my personal checklist.

Last year, I gave myself the goal of wanting to speak on technical topics more publicly. I was happy to present at Microsoft TechDays here in Winnipeg with an Introduction to ASP.NET MVC on December 16.

Little did I know I would be speaking to around 100 people on this topic. For a novice speaker, a little intimidating, but gratifying. (It seems no one knew my laptop crapped out the night before and my demo was thrown together 9 hours before the presentation.)

But this gave me a step forward to help with my 2010 Early Resolutions.

• A better balance between personal and work life. I have a tendency to work too hard, to be a perfectionist, and let the personal life slide. Sometimes working so hard I make myself ill – like today as I write this. This will be corrected in the new year.
• Be a better motivator and coach rather than a boss. Instead of dictating everything, work more in collaboratively. Listen. Not get upset. Build up the team environment rather then the “US vs. THEM” mentality. I’ve read a few great books on leadership recently (reviews pending) and it inspires me more as to the kind of leader I want to be.
• Speak more. I have already committed (and been accepted) to 2 presentations at DevTeach in Mississauga in March (one on SketchFlow and another on jQuery). I am planning on doing a presentation at the Winnipeg Code Camp in February (topic TBD). I am considering putting together a few abstracts to submit to MIX (one of the largest web conferences). Speaking means you know your stuff, and this forces me to become knowledgeable in these areas.
• Become more proficient in new technologies. My day-to-day is no longer coding, but I need to know what’s out there. We are becoming, more and more, of a full service provider to our clients so we need to know what’s out there and what is available. As an analyst, I need to know to provide options and direction. I need a stronger pulse on what’s going on in industry.
• Read more “inspirational” books. To me, these are more business biographies and stories, either about the company or the person. Some of the most interesting I have read have nothing to do with technology, but the practices within are invaluable. I want to read at least one per month (on average). Recommendations are greatly appreciated.

Well, that’s my starting point. They are all somewhat tech oriented, and I am sure that more will come up. But this is a nice starting point. It gives me something to move forward to.

As it is now the 22nd and I still have to finish my gift shopping, I leave now, wishing everyone a great holiday (regardless of what you celebrate) and hope to post much more frequently in the future.

I have now played around with ASP.NET MVC Framework 1.0 over the last few months in great detail. I first was introduced to this framework at DevTeachthrough a presentation from the gift to software developers, Justice Gray. A new web framework that was not control-based (and no ViewState) sounded good, as many of the projects I have worked on are not necessarily web applications but public-facing, information-providing web sites and some of the elements and controls in WebForms is a tad overkill and performance draining at times.

I recently read and commented on the book “Professional ASP.NET MVC 1.0” in my blog. In that post, I indicated that what I thought was missing from the book: reasons and justifications of when to use one over the other. The book was technical in nature (as it should be), but my experience is that developers want to use newer things and they need to be able to justify a newer technology to their boss instead of just “because it’s there”. So, what follows are my opinions on when to use WebForms and when to use ASP.NET MVC (I’ll just call it MVC for the purpose of this post – I won’t be referring to any other MVC frameworks at this time). These are just opinions and are based upon where I see the strengths of each of the systems.

WebForm Strengths

I think the main strength of the WebForm framework is its ability to run as an true application environment. It’s initial design was to make the transition from a desktop environment to the web, otherwise there would be no such thing as ViewState. Why would you need state for a standard website? You wouldn’t. Maybe for a shopping cart system, but a secured website and cookies fit the bill there.

There are enough third party controls out there with cool things that they do that WebForms will not go away, nor should it. For the longest time it was the only player on the block; having competition, even if from the same parent, can only make it better. As well, many organizations have a lot of time and effort invested into WebForms applications so why should it go away? It shouldn’t; it has its purposes and it works great for those.

MVC Strengths

A strength of MVC is its ability to deliver content through URL routing. Yes, I know that the routing engine is available to use through WebForms too, but I think it’s ability as an inherent part of the MVC system is a major strength. I mean, compare these potential URLs:

http://www.blah.com/DoSomething.aspx?action=blog&id=MVCPost

http://www.blah.com/Blog/MVCPost

Of those 2 URLs, which one is easier to read (from an end user POV)? Which one is easier to understand where you are? Definitely the second, which takes full advantage of the routing engine in MVC. As well, MVC focuses on strong separation of the view from the logic; WebForms… not so much (it can, but with many developers focusing on a technology instead of a best practice, you don’t see this as much).

Where Could They Be Used Together?

I could see both technologies being used to create a full deliverable solution:

• A WebForms application being used to create the support interface for a content management system
• MVC being used to deliver the public-facing result of the CMS

Why would I see it this way?

• The CMS needs to be able to set content on multiple templates. Only authenticated users should be able to do this, not everyone who has access to the site. Being able to manipulate content (images, text content, page templates, activation and expiration dates of content) is inherent to application-style functionality. The ability to manipulate content seems much more in-place with the purpose of the WebForms infrastructure.
• The public-facing site (content delivery) would be much more suited to MVC. MVC merely has to extract the information it needs and provide it through the controller and model to the view, which handles all UI elements. For the most part, modules within a CMS are (should be) reusable and as such just need a mechanism to display them, and MVC provides that quite easily.

Now, I am not saying that you cannot or should not use one technology for the infrastructure or public delivery over the other; it’s personal preference. However, I think MVC gives a few extra bonuses for a public site that needs value to be applied to it:

• Native routing engine that gives more user-friendly URLs, which makes metrics gathering that much more simpler to do (if done client-side)
• Page settings are easier to control (page title, etc.)
• No worries about third-party WebForms controls displaying strange raw HTML (it has been known to happen)
• Adding a new visual piece of functionality does not inherently mean changing every element of the application, whereas with WebForms you may have to do so (not always)
• Full control over the UI means the potential for enhanced search metrics

I am focused greatly on metrics, usability, and enhancing a website with work these days so thinking of how I can enhance an application… well, MVC seems to have these things more “out of the box” which means faster turnaround, which means more value, which also leads to more work to make things better. WebForms has its place, but public-facing content delivery sites (IMO) is not one of them.

There is a mantra out there in software these days: “The right tool for the job.” It really takes an understanding of the technologies out there to make this call, and knowing its capabilities really seems to help. Having only a one-sided view limits the potential for enhancement and value; you really need to understand what is going on and go in with the mindset of delivering something quality, but also with a system that can help make things better.

Professional ASP.NET MVC 1.0 (Wrox Programmer to Programmer)
by Rob Conery, Scott Hanselman, Phil Haack and Scott Guthrie
Published by Wrox Books
ISBN: 978-0-470-38461-9

I finally had the chance to complete this book. This has been a very long summer, and my hope was to finish this by the end of June. No such luck. I only just finished it this September long weekend after trying to find some time to do it, but that was not to be. I am happy to say that I have now completed it, and it was worth its time to actually take some time.

The Good

This is definitely a good book for someone already familiar with coding in C#. You don’t have to be a C# guru (thank God for that), but you have to understand the nuances of the language. Understanding the ins and outs of ASP.NET helps too so that you can truly understand the difference between the MVC framework and WebForms.

The book has 420 pages made up of 12 chapters. This should not seem daunting, though; the first chapter alone takes up the first 164 pages of the book, but is a complete step-by-step walkthrough of an ASP.NET MVC application called Nerd Dinner. It gives and intro to virtually every concept that the MVC Framework 1.0 covers without delving into too much detail; the detail follows in the other 11 chapters.

Each subsequent chapter contains a singular topic that allows the reader to focus and they actually flow well into one another: Routing to Controllers and Views to TDD. This book covers a lot of the main topics that a developer who delves into MVC will need (I especially like the TDD chapter – definitely a boon for someone who never saw the value in TDD until recently, but that was simply because I never truly understood the value).

I do like the fact that this book did not jump into jQuery. The authors mention at the start of Chapter 7 that jQuery will be supported within ASP.NET MVC but do not delve into it. Why not? Because there are many books on jQuery out there that can cover the topic there. jQuery is also not native to just MVC so it makes sense not to cover it here, but I am glad that they did make mention of the technology.

They also mention that WebForms and MVC can exist in the same project. What? Touting the fact that the technology being used is not the only solution out there?? Inconceivable! And yet, it’s great to see a compare and contrast view, and then a “But we can work together by…” methodology being demonstrated.

I also enjoyed the “Product Team Aside” sections. What is nice about this book is that it is written by 4 individuals who actually worked on the product team within Microsoft. That means that they truly have an inside track as to what is going on with the technology and give a birds-eye view of it. There are far too many books that are used by experts in the technology, but with only personal experience and no knowledge of where it is going. (Although they don’t outright say where MVC is going in the book, a logical assumption is that they aren’t going to focus on a feature that they know is going to be dumped – the primary advantage of the product team writing it is that it is not someone making an assumption and posing in a book “Why is this not there?”.)

The Bad (AKA What I Think Would Be Better in the 2nd Edition)

What I mean to say here is not necessarily bad, but just something I think could have been better.

Being one of the few books that gives you a full tutorial from beginning to end, one thing I found disappointing was the fact that some of the code presented in the book just simply wouldn’t compile. I followed every step-by-step instruction and it worked for the most part, but once I hit a certain threshold it just wouldn’t work. (Thankfully, the authors provided the application online for download. By downloading that you could get the application to compile, but it was the final version so you really had to jump around and grasp a lot of things at once.)

I think it would have been better had Chapter 2 actually been Chapter 1 – a comparison of MVC frameworks, a high-level discussion of what it does (not in-depth) and then dive into the tutorial as a second chapter. (Don’t get me wrong – I love the idea of the full application tutorial, not enough books give this kind of in-depth summary from beginning to end; I just don’t necessarily agree with it as the first chapter.)

This is something I am putting under bad, but it’s not bad; I hope that by putting it here that if the authors read this post that they will consider it for a future edition, and that it also sparks some discussion/debate: Put more emphasis on the testing. There were 2 chapters in the book which covered TDD and testing patterns, but I don’t think that was enough. The MVC framework is such that this is the perfect technology to truly expand upon the testability of software applications and bring a higher level of quality to the applications. With proper tests, confidence in the quality of the application goes up and value of the application (and the development team) also goes up. Far too often, testing comes as an afterthought if at all; partly because many frameworks do not truly support how it can function. This framework endorses the testing platform from day one, and I think not enough attention was granted to it. (I know it may have made the book bigger, but considering the size of some other technical books an extra 2-3 chapters on testing your MVC application would not kill anyone.)

The Nitpicky

I am pretty nitpicky a lot of the time. Although well written, you could tell that this book had 4 authors. You could tell frequently when one person wrote one section or chapter and then another took over; their personalities (especially if you read their blogs) stood out as did their writing style. I am pretty sure that much of the identification was taken out during the editing phase, but you can’t get it all. (You also can’t please all of the people, which is why this is not a bad thing, but merely a nitpicky thing.)

What I Would Have Liked To See

The book really does cover the advantages of MVC over WebForms, but also talks about the advantage at times of WebForms over MVC. What it does not cover, in my opinion, is when you would want to use MVC over WebForms. The book is (and intentionally so) technical, but my experience is that an organization wants their people to make recommendations and relate it back to the business element and why they should choose a current technology. Many companies may not even want to look at MVC 1.0 because:

1. It’s a version 1.0 product
2. This framework may not yet be “proven” to an organization that has a deliverable arrangement necessary
3. It’s considered to be merely a new “flavour of the week”

Although there are many great technical reasons to choose MVC, there is no way to convince a non-technical (or even someone technical who would understand it but is set in their ways) why you would want to use this framework for a client deliverable. (I will touch on what I think the best case for MVC versus WebForms should be in an upcoming post – probably to be written shortly after I post this one.)

Summary

I may sound somewhat negative, but I am not. Not about this book. This is one of the better technology-related books I have read in a long time. It covers the technology in detail, it gives great examples, it gives ideas of where the technology is going, and it shows that it’s not the only solution out there. It can co-exist with other, similar technologies and continue to grow. My negatives are not really negatives, just more personal preference; there is nowhere here where I said that “this sucks” or anything along those lines, because it doesn’t. This is a well brought-together book which drives people to understand this new framework (already in 2.0 Beta – I knew I should have read faster). It isn’t the end-all, be-all; it is simply another option. And I think it’s a good one that’s only just getting started.