Is WPF Going Away?

Everyone asks "Is Silverlight replacing WPF?" All the buzz is about Silverlight. Many of the innovations in UI (controls, validation, navigation) are offered first in Silverlight while WPF plays catch-up.

Tim Heur wrote about it in his blog this week ... and that got me thinking about it yet again.

Official Microsoft keeps saying "No. See, we're betting on WPF ourselves." And, indeed they are; substantial portions of Visual Studio 2010 are written in WPF for example.

Let's take them at their word and assume Microsoft will keep WPF both alive and vibrant.

The better question, perhaps, is which technology is right for you?

Jaime Rodriguez offered the best comparative analysis that I've seen on the subject in his blog post of March 30th. He summarizes it as a trade-off between full features and full-trust (WPF) vs. reduced features and reduced trust (Silverlight). "Why wouldn't you leverage the full power of WPF if you could?"

That's a reasonable case. Being a guy who wants the biggest Swiss Army knife on the bock, I'm with Jaime by instinct.

On the other hand, if I listen for it, I can hear the Agilist counter argument: "Why carry the load of features and responsibilities you're not using?" And then there is the ever important matter of "Where do I find developers who are good at WPF?" If most developers are writing Silverlight, the economics lead me away from writing in WPF even if it is technically better suited for my application.

I think you have to ask "Who are the end users of the application?" If they reside outside of the sponsoring organization, it seems to me that Silverlight is the right call.

If I'm an ISV, "Silverlight" is almost certainly the preferred choice. If you absolutelly have to have access to the client hardware, I guess you'd hazard WPF. But even with all the gaps (the lack of printing in Silverlight is near the top of my list), I'd still go Silverlight and live with work-arounds if I could.

Frankly, I am through trying to convince customers that they'd be better off with smart client. That's a great way to waste time evangelizing instead of selling. It doesn't matter that WPF smart client is better or that you could deliver the product sooner in WPF. Because somewhere between 10% and 20% of your market thinks the application must run in the browser and won't let you install it. They won't fall for the XBAP either. As one sage told me: "Would you rather be right or would you rather be effective?"

Maybe you could do both at the same time? Just write one code base and skin for WPF or Silverlight as needed. They're both pretty close, right?

WPF and Silverlight programming models are getting closer all of the time. I've had decent success getting a lot of my code ... even ViewModels ... to be textually identical across the platforms. And we do have important customers who use our product to drive both ASP and WinForms client applications ... a route that is much more challenging; I might have encouraged a WPF/Silverlight hybrid if that had been an option at decision time.

But I fear such customers are relatively rare. Few folks can make a serious business case for maintaining a single code base that drives both WPF and SIlverlight. It takes a lot of energy to maintain that cross platform compatibility where it counts: in the UI and Presentation layers.

Do any of you have examples? I'd prefer real-life examples but I'll take speculative ones too.

Entity Framework Jargon

Alex James of the Entity Framework team has eased our pain a hair with another nice tip, Tip #10, "Understanding Entity Framework Jargon".

Ever wondered what C-Space, S-Space, O-Space and all such variations mean? Alex gives you a clue.

There's way more jargon to gloss than he covers here but it's still worth a visit.

Entity Framework Inheritance

Alex James of the Entity Framework team has been posting tips on Entity Framework practices. You'll find an index to them here; I'm confident he'll maintain it well.

In this post I'm drawing your attention to Tip #12, Choosing an Inheritance Strategy, which is a nifty summary of the issues and tradeoffs for choosing among Table Per Hierarchy (TPH), Table Per Type (TPT) and Table Per Concrete Class (TPC) database representations of class inheritance.

Don't know what those are? Alex is pretty clear on that too.

Which strategy is best?

It depends (hey, ain't that a shock).

Alex walks through the considerations simply and clearly. And, while Alex discusses the choices from an Entity Framework perspective, everything he has to say applies generally. The excellent book "NHibernate in Action" explores this territory well (pages 91-99) and offers similar advice.

Here is the "dirty little secret": inheritance mapping is the most over-hyped feature of sophisticated ORMs.

You rarely need it and you can get into lots of time-wasting trouble.

Yes, I use it from time to time; I like TPH for "code" classes where you're trying to manage thirty or more simple "enumeration-like" classes such as Status, Color, UnitOfMeasure, EmployeeType, etc. All of them have pretty much the same {Id, CodeName, Description} structure.

But I usually avoid inheritance mapping and its attendant complications.

The "NHibernate in Action" authors said it well:

[A]sk yourself whether it might be better to remodel inheritance as delegation in the object model. Complex inheritance is often best avoided for all sorts of reasons unrelated to persistence or ORM. [Your ORM] acts as a buffer between the object and relational models, but that doesn't mean you can completely ignore persistence concerns when designing your object model. [p.98]

I hear echos of that familiar, sound advice: "favor composition over inheritance".

Binary Serialization comes to DevForce for Silverlight

We'll offer binary serialization (aka "Binary message encoding") in the next version of our "DevForce for Silverlight" product. We're quickly incorporating Silverlight 3 features and this is an important one. We had to rely on text encoding heretofore because that's the best that Silverlight 2 could offer.

Read this to learn why binary serialization matters. According to Microsoft, we should be seeing smaller payloads and better service performance. This March 9th bulletin promises "a follow-up post ... with some specific data on the improvements that can be expected"; haven't seen such follow-up yet and we haven't measured the difference ourselves ... yet. It sure makes sense in theory. More on this subject when there is more to say.

Reinvigorating the Blog

Have you been reading blog posts in which the author swears to blog more. Me too. And I'm joining them.

Why? Because my vast audience has been clamoring for posts! Err ... maybe not. But a silent blog is a dead blog and only through frequent practice do we achieve anything worthwhile.

What keeps me from blogging more and more effectively? It ain't writer's cramp. I write all day long.

I think it's because I feel that my posts have to be profound. Well, I'm not profound every day. And, as I review my history here, I'm a far piece from profundity anyway.

So I'm going to try two things:

First, I'm going to keep 'em short and simple.

Second, I'm going to write about what we're doing here at IdeaBlade.

Let's see what happens, shall we?