Programming MVC2 is out with code
The sample code for my latest book Programming ASP.NET MVC (covers version 2 and 2010) is available via the book's catalog page at Microsoft Press site run by O'Reilly.  You click the Examples link here to get to it: http://oreilly.com/catalog/9780735627147/
Posted 12 June 2010 09:59 AM by despos | 4 comment(s)
Crushed by complexity—me too, and for a long time

I had no sessions on ASP.NET MVC in this Fall DevConnections, but I’ll have quite a few in the upcoming Spring 2010 event which will coincide with the Launch event of VS 2010. Yet, many of the questions I got at the end of my sessions (code design, domain model, social network applications, jQuery UI) revolved around ASP.NET MVC and, as one nicely said, my recent conversion to it J

Technically speaking, it is not a matter of a conversion.

I didn’t change my mind about it. More simply, I decided to have, at last, a non-superficial look at it. I got to know it, and I recognized its inherent superior architecture, its core simplicity, its extensibility that largely stems from proper class design. It is so extensible that … it can be made any complex and sophisticated without impacting people just looking for a close-to-the-metal framework.

This is a stunning point compared to Web Forms.

In Web Forms you have to fight to achieve simplicity (the definition of simplicity generally agreed on in 2009), and you can hardly have it cheap, and often you can hardly have it full. In ASP.NET MVC, instead, you currently have to fight to have some good complexity and abstraction in the view. Still provided that wanting a grid can be considered a form of complexity.

So why did I toughly disregarded ASP.NET MVC from about one year since its inception? Let’s look at the dates.

·         October 2007: Microsoft releases the Preview 1 of ASP.NET MVC. And I was among the first to write a comment (see DotNetSlackers.com) and to emphasize its real REST nature versus the alleged MVC-ism.

·         October 2008: After a wave of Preview X, Microsoft releases Beta 1. And I started on it—very slowly—but started. My articles on aspnetPRO (now DevConnections magazine) witness that, as they start with the January 2009 issue.

·         March 2009: Microsoft releases v1.0. And I see the (green) light.

Now what?

Hey, but in this way you didn’t help Microsoft to build to product. I don’t work for Microsoft. I work for myself and another company—and it’s hard enough J

Hey, but in this way you didn’t help the community (and yourself) to have a better product. Well, this is a more delicate point that probably has a lot to do with what I really do every day. I do help clients building their own systems, but I’m hardly sitting writing production code. All I need is, knowing a number of products/frameworks deep enough at their core to deliver classes, write books, create prototypes and proofs of concept, and fix hard design issues. (Little detail—with a bit of money attached.)

Hey, so you want to be paid to share your high thoughts on Preview 345 of any SomePieceOfSoftware framework? As long as previews come out every four weeks or so (not to mention nightly builds you can optionally look at), well, it’s a lot of (my) time. It means subtracting time to projects, clients, family, friends, and worst of all, tennis J  Getting a return doesn’t necessarily mean getting some cash, however. It just means getting a return of any type that has value for you. Quite simply, I don’t see any value for me in previewing CTP 4 of the 3rd week of 7th month of the year.

There’s a popular proverb we use in Italy (it probably exists in other languages too) that is used to celebrate the old good times. It says “there’s no more the half-season” and it is used typically to complain about the weather too hot in April or too cold in October. The common wisdom expects some sort of transition between changes in season.

In software, we always had sharp changes—from version N to version N+1. But now on the wave of open-source and community-driven projects, in software we are having the concept of the half-version introduced. And worse yet the transition is getting longer and longer. The granularity of the release breaks in smaller pieces every day. The average number of Previews grows, followed by a few CTPs, then Beta 1, then Beta 2, then a few RCs, and finally RTM.

Is it all of it? Not yet. There’s an immediate SP1 for anything that didn’t make it in the RTM and perhaps a R1 or R2 later on.

The software product is like a mutant virus—you don’t know its direction (and it can get worse at any time) until it reaches the Beta 2 stage. After that, it will certainly mutate again but is now harmless for developers J

“Crushed by complexity” is the title of a session that Billy Hollis delivered at DevConnections. Unfortunately, I couldn’t be there but whatever he said I feel I agree J

Posted 12 November 2009 04:37 PM by despos | 14 comment(s)
Filed under: ,
ASP.NET MVC is MUCH better than MS seems to think

Here at DevConnections I just attended the ScottGu’s keynote on Visual Studio 2010 and Web development. I haven’t had much time to spend on the latest Beta of Visual Studio 2010 yet so I found most of the information quite helpful and interesting. It looks like Microsoft is finally coding some good functionalities from ReSharper and .NET Reflector inside of Visual Studio 2010.

Little gems like “Generate stub method” or “Display the hierarchy of calls” are now available natively. Still ReSharper is a must I think, but it is good to have a really better VS. By the way, I haven’t seen yet a preview of ReSharper for VS 2010 so the gap might still be quite large J

My primary focus these days is for ASP.NET MVC as I’m doing—guess what—a book scheduled for the release of the .NET 4 platform next April. I particularly loved the TDD spin of ASP.NET MVC that is visible from tooling support. I’m not simply emphasizing the possibility of doing unit tests; I’m referring to the possibility of writing tests first and then the code. And here’s that facilities like stub method and types generation come into play.

And finally, I respectfully but strongly disagree on the slant of many Microsoft presentations that touch on ASP.NET MVC. I disregarded ASP.NET MVC for too long. Now that I got to know it from the inside, well, it’s the best (large) piece of code I’ve seen for a long time.

It’s much better than MS seems to think and tell.

In my opinion, it really represents the way to go for most developers in the mid term. It is probably premature to suggest today that Web Forms be abandoned to embrace ASP.NET MVC. But the new framework (in version 2.0 with Visual Studio 2010) drives you toward better code. Don’t get it wrong: ASP.NET MVC doesn’t automagically make your code clean, elegant and flexible. You still have to go a long way ahead but it puts you on the right track and delivers an environment where you can write testable and practice seriously with unit testing.

A point that Scott made about ASP.NET MVC is that it gives you total control over HTML. Not that this is a false statement, but it happens because server controls are marked as evil. They still work (even though their use may compromise the design—hold on) if you want and if you use the increase your distance from HTML. But on the other hand, if you stop using server controls in Web Forms you get closer to the HTML metal also in Web Forms. So in the end the reason for using ASP.NET MVC is Separation of Concerns and testability.

Eventually, Microsoft will be able to add that to Web Forms too, perhaps via the MVP pattern as the Web Client Software Factory framework attempted to do a while back. 

Posted 11 November 2009 07:08 AM by despos | 21 comment(s)
Filed under:
The dead-end of Web Forms

I had a talk last week at BASTA about ASP.NET MVC vs. Web Forms and I repeat the same talk today here in London at Software Architect conference. (Well, repeating a session is a big term for me--I'll never be able to repeat the same session the same way two or more times...).

The key question that people ask, the only answer they want to hear, is about which one is preferable to use for the next project. Clearly, the natural answer would be a classic "It depends". My rule of thumb is fairly simple

  • If ASP.NET works for you, then stay with it.
  • If you start complaining about limitations you experience (not limitations others say you are experiencing), then look ahead.
  • Once you decided to take the plunge into ASP.NET MVC go ahead and never hesitate. If you seem not understanding it very well, study it more.

When introduced, Web Forms was a cutting edge solution and it just engineered current best practices. But it was ten years ago. We could argue whether it was the right choice to engineer ASP practices ten years ago. In fact, more or less at the same time Sun did it differently when they architected JSP.

There's not much more you can expert or achieve with Web Forms than you do today. OK, tomorrow, with version 4. This is the dead-end of Web Forms.

If it doesn't serve you any more the way you like, change it. It will be a change for the better. But the better is also different and requires a different approach and skills. Design is design, and with ASP.NET MVC (which is far from perfection, by the way...), you need to gain design and architecture skills.

My next book is just on ASP.NET MVC (February 2010) and will target version 2. Like many other books of mine it won't be an how-to book. And I'm taking architecture and design very seriously as I explain controllers, views and models. Stay tuned. And plan your design training :) Contact me... ha ha ha Smile.

 

 

 

 

 

Posted 01 October 2009 04:01 PM by despos | 16 comment(s)
Filed under:
Silverlight Coding Contest

A few days ago, ComponentArt started a Silverlight coding contest. If you submit your Silverlight applications for evaluation by the "Esteemed Panel of Judges" you can win a prize of $10,000 or get free licenses to ComponentArt products if you happen to be one of the two runner-up. Much more details available at the following sites:

 

- http://www.componentart.com/ - http://www.componentart.com/community/competition2009/ - http://www.componentart.com/BLOGS/miljan/archive/2009/06/22/10-000-for-the-best-silverlight-app.aspx

BTW--I'll be one of the esteemed judges :)

Posted 02 July 2009 05:30 PM by despos | 3 comment(s)
Filed under:
DataForm Control in Silverlight 3

Silverlight 3 comes with a new control—the DataForm control—through which you can design a view model around a data type in what actually results to be a specialization of the MVVM pattern. The DataForm control is also smart enough to analyze the public properties of its data source and generate some UI accordingly. The DataForm will use text boxes for string properties, check boxes for Booleans, and a date picker control for dates. If bound to a collection of objects, it will also display a navigation bar.

Read the full (part I of the) story on DotNetSlackers.com.

Posted 02 July 2009 05:25 PM by despos | 3 comment(s)
Filed under:
ASP.NET 4.0: more control on viewstate management

ASP.NET is a stable and mature platform for building Web applications. Personally, I can hardly imagine a revolutionary set of new and  compelling features to be added to it. So what's new in ASP.NET 4.0? Beyond AJAX stuff, there are some interesting enhancements in the Web Forms area. As I see things, all changes in ASP.NET 4.0 can be catalogued under the label of "more control". You get more control over viewstate, script references, ID generation, output caching and even, but in very limited form, over HTML generated by some controls.

Let's briefly focus on the viewstate extended control. In ASP.NET, the viewstate is optional but it is enabled by default. In addition, the viewstate is not simply a way of reducing your bandwidth. It is rather functional to the implementation of the Web Forms model. So just dropping the viewstate in a new version of ASP.NET is simply out of question: either you get a new ASP.NET platform such as ASP.NET MVC or you stick to Web Forms with the viewstate on board.

However, there's a subtle aspect of the viewstate management that has been fixed in ASP.NET 4.0. I said fixed because, well, from my perspective it had to be considered a bug-by-design in previous versions.

All server controls (the Page class derives from Control) have the EnableViewState property through which you can disable the viewstate for that control. What is little known ais that the EnableViewState property is ignored for child controls. In other words, if you take the default value (true) for the page, then whatever value you assign for it to any controls in the page... it is ignored. You can have have TextBox1.EnableViewState = false but still have the text box to read/write state from the viewstate if the viewstate is enabled at the page (or container) level.

This will change in ASP.NET 4.0 thanks to the new ViewStateMode property.

This property indicates whether the viewstate for the control is enabled|disabled|inherit. You can use the ViewStateMode property to enable view state for an individual control even if view state is disabled for the page. This is the great news. Finally, you can now disable the viewstate on the page and decide which controls will have it enabled (opt-in). In earlier versions you could only do the reverse (opt-out): enable the viewstate and then decide which controls will not support it.

 

 

 

Posted 13 June 2009 10:04 PM by despos | 24 comment(s)
Filed under:
Give a chance to prediction

It is mostly about AJAX applications, but it applies well to any scenario where a smart/rich client is present. I'm talking about the "Predictive Fetch" pattern. Quite simply, it refers to the idea of preloading data that the current user can request in a few moments. It relates to caching--more, it is often implemented through caching--but it is a different kind of thing. It is actually a strategy for certain pieces of the user interface, where you need/want to exceed expectations and provide an output close to (if not under) the threshold of human consciousness (about 10 ms). Immediate response.

Like many other AJAX-related things, it is mostly a matter of tradeoff. You are guessing, that's what you're doing. And the guess can be right or wrong. If wrong, you have just wasted some resources and CPU cycles on both client and server. If right, you astonish users. BUT... because you can hardly afford pre-fetching from every possible use-case, then the open point is: what the user reaction/feelings when one feature is sooo fast and another similar one is slower?

The full story on DotNetSlackers.

Posted 21 May 2009 10:04 AM by despos | 1 comment(s)
Filed under:
Testability vs. Testing

The first time I heard the expression "unit testing" at a .NET conference was--if memory serves well--back in 2004. Since then, it took probably a couple of more years for the theme of "unit testing" to gain due visibility in the .NET space. I can't mention a date when I heard the word "testability" instead. And still in articles, blogs, and conference talks the prevailing term is "testing". Not that no conferences in the world had the word testability pronounced lately, but it never happened to me to attend a talk or something where I could hear it--maybe I just go to the wrong sessions and miss a lot of great events :)

Seriously, I feel that the word "testing" is used much more frequently than the word "testability". And I do believe that for developers and, especially, architects testability is a far more important aspect. In first place, testability is one of the required attributes of any software system according to the ISO standard for software architecture. Second, testability has a deeper impact than testing on the quality of the code you write. What's testability?

In our book "Architecting Applications for the Enterprise" Andrea and I write it as follows:

A broadly accepted definition for testability in the context of software architecture describes it as the ease of performing testing. And testing is the process of checking software to ensure that it behaves as expected, contains no errors, and satisfies its requirements.

In a nutshell, testing returns you a working application; testability returns you a better designed code. Honestly, can you spot any difference between a unit-tested piece of code that works and a piece code that just works (maybe tested by simply poking around)?

With the excuse of letting you do that cool thing called unit-testing more quickly and effectively, testability silently drives you towards a much better design of the code with plenty of SoC, dependency injection, low coupling, high class cohesion, and minimal responsibilities for classes.

Ultimately,design for testability means applying a software contract (code-contract in .NET 4.0) to classes and methods and keep classes cohesive, loosely coupled, and with dependencies clearly listed. Once classes are testable, unit-testing them is really a little detail.

 

 

 

Posted 13 May 2009 11:26 AM by despos | 4 comment(s)
Filed under:
Things to say

Two interviews out at about the same time. One is on mythical DotNetRocks; one is on SodThis--brain burps for the tech savvy. Love the payoff :)

 Enjoy!

Posted 03 May 2009 09:33 AM by despos | 1 comment(s)
Filed under:
More Posts Next page »