Rockford Lhotka

 Monday, July 30, 2012

I want to summarize some of the more major changes coming to the data portal in CSLA 4 version 4.5. Some of these are breaking changes.

I’ve done four big things with the data portal:

  1. Added support for the new async/await keywords on the client and server
  2. Merged the .NET and Silverlight data portal implementations into a single code base that is now common across WinRT, .NET, and Silverlight
  3. Removed the public virtual DataPortal_XYZ method definitions from Silverlight, because it can now invoke non-public methods just like in .NET. Also, all local Silverlight data portal methods no longer accept the async callback handler, because they now support the async/await pattern
  4. Remove the ProxyMode concept from the Silverlight data portal, because the RunLocal attribute is now available on all platforms

All four have some level of breaking change.

Adding comprehensive support for async/await changes the way .NET handles exceptions. Although I’ve worked to keep the top level exceptions consistent, the actual exception object graph (nested InnerExceptions) will almost certainly be different now.

Merging the .NET and Silverlight data portal implementations introduces a number of relatively minor breaking changes for Silverlight users. Though if you’ve created custom proxy/host pairs or other more advanced scenarios you might be more affected than others. There may also be unintended side-effects to .NET users. Some might be bugs, others might be necessary to achieve platform unification.

Removing the public virtual DataPortal_XYZ methods from BusinessBase and BusinessListBase will break anyone using the local Silverlight data portal. The fix is minor – just change the public scopes to protected. This change shouldn’t affect anyone using .NET, or using a remote data portal from Silverlight.

Removing the async callback parameter from all Silverlight client-side DataPortal_XYZ methods will break anyone using the local Silverlight data portal. The fix is to switch to the new async/await pattern. The code changes are relatively minor, and generally simplify your code, but if you’ve made extensive use of the client-side data portal in Silverlight this will be a pretty big change I’m afraid.

Similarly, removing the ProxyMode concept from the Silverlight data portal is a breaking change for people using the local Silverlight data portal. Again, the fix is pretty simple – just add the RunLocal attribute to the DataPortal_XYZ (or object factory) methods as you have always done in .NET.

On the upside, the coding patterns for writing code in .NET, WinRT, and Silverlight are now the same.

For example, a DataPortal_Fetch method on any platform looks like this:

private void DataPortal_Fetch(int id)

or like this

private async Task DataPortal_Fetch(int id)

The data portal will automatically detect if your method returns a Task and it will await the method, allowing you to use the await keyword inside your DataPortal_XYZ methods.

Similarly, all platforms can now write this client-side code:

var obj = await CustomerEdit.GetCustomerAsync(123);

or the older event-style code:

CustomerEdit.GetCustomer(123, (o, e) =>
      if (e.Error != null)
          throw e.Error;
          obj = e.Object;

Only .NET code can use the synchronous approach:

var obj = CustomerEdit.GetCustomer(123);

This is one of the few platform-specific concepts left in the data portal.

What is really cool is that the client and server sync/async concepts can be mixed (as long as you know what to expect).

Client method Client platform Server method Server platform Remarks
Fetch .NET only void DataPortal_Fetch any Client call is synchronous; server call is synchronous
Fetch .NET only Task DataPortal_Fetch any Client call is synchronous; server call is asynchronous; note that client will block until the server’s work is complete
BeginFetch any void DataPortal_Fetch any Client call is asynchronous (event-based); server call is synchronous; client will not block, and must handle the callback event to be notified when the server call is complete
BeginFetch any Task DataPortal_Fetch any Client call is asynchronous (event-based); server call is asynchronous; client will not block, and must handle the callback event to be notified when the server call is complete
FetchAsync any void DataPortal_Fetch any Client call is asynchronous; server call is synchronous; client will block or not, depending on how you invoke the client-side Task (using await or other techniques); the client-side Task will complete when the server call is complete
FetchAsync any Task DataPortal_Fetch any Client call is asynchronous; server call is asynchronous; client will block or not, depending on how you invoke the client-side Task (using await or other techniques); the client-side Task will complete when the server call is complete

I expect all client-side data portal code to switch to the async/await versions of the methods, and so I’ve made them the mainline path through the data portal. The synchronous and event-based async methods use async/await techniques behind the scenes to do implement the desired behaviors.

There is a lot of variety in how you can invoke an awaitable method like FetchAsync. The specific async behaviors you should expect will vary depending on how you invoke the method. For example, there’s a big difference between using the await keyword or the Result or RunSynchronously methods:

var obj = await CustomerEdit.GetCustomerAsync(123);

var obj = CustomerEdit.GetCustomerAsync(123).Result;

The former is async, the latter is sync. The former will return a simple exception (if one occurs), the latter will return an AggregateException containing the simple exception. This has little to do with CSLA, and nearly everything to do with the way the async/await and task parallel library (TPL) are implemented by .NET.

Finally, I do need to state that the actual network transport (typically WCF) used by .NET, Silverlight, and WinRT aren’t the same. This is because WCF in .NET is far more flexible than in Silverlight or WinRT. And because the WCF client-side proxies generated for Silverlight use event-driven async methods, and in WinRT the proxy is task-based.

The data portal hides these differences pretty effectively, but you should understand that they exist, and as a result there may be subtle behavioral differences between platforms, especially when it comes to exceptions and exception details. The success paths for creating, fetching, updating, and deleting objects are identical, but there may be edge cases where differences exist.

All in all I am quite pleased with how this is turning out. I’ve put a massive amount of work into the data portal for 4.5, especially around unifying the implementations across platforms. I suspect there’ll be some issues to work through during the beta testing phase, but the end result is a far more consistent, maintainable, and streamlined codebase for all platforms. That will benefit all of us over time.

Monday, July 30, 2012 10:53:23 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Wednesday, July 11, 2012

In a word: yes.

My post is spurred by discussions I’ve had around this recent article:,16190.html#xtor=RSS-998

And my post is motivated by the fact that I’ve had an i5-based Windows 8 tablet for a few months now, and have direct experience with the idea of using a tablet as a desktop/laptop replacement.

First, understand that I have:

  • A tablet with an i5 CPU, a decent GPU, 4 gb RAM, and an SSD
  • A docking station for the tablet with USB and HDMI ports
  • A bluetooth keyboard
  • A bluetooth mouse

On this tablet I have installed:

  • A variety of WinRT/Metro style apps
  • Office 2010
  • Visual Studio 2012
  • Expression Blend
  • Microsoft Lync
  • DropBox and the Win7 SkyDrive client

Second, understand that I also have a high-end desktop (for dev work and gaming), and an i7-based laptop for dev work. The laptop is also running Win8, and the desktop is still Win7.

Third, I’m a big guy. I’m 6’5” tall, with broad shoulders, and big hands. Netbook keyboards are a joke, nearly useless. Normal laptop keyboards cause me great wrist, arm, and shoulder pain. Only Microsoft Natural keyboards allow me to type for any length without discomfort.

Given that background, here’s my normal usage profiles.

My Home Office

I use my desktop for most things, because it is all set up with a Microsoft Natural keyboard and multiple monitors. It is just comfortable, and all my games are installed on this machine, as is VS10 for work on .NET 3.5 stuff.

Also I’m a gamer, and I have a friend who custom-builds my desktop computers. So I always have a top-end dev/gaming rig for a fraction of the cost to get a comparable laptop. And I have yet to see anyone talking about a “gaming capable” tablet – not at the level of gaming oriented tablets or desktops. Were there to be a tablet that could run Battlefield 3 at high res and no lag, AND without me needing a second mortgage on my house, I’d consider getting rid of my desktop.

My Magenic Office

I use my laptop (Win8) for most things, because I have a nice docking station connected to multiple monitors and a Natural keyboard. My laptop also has Office, VS10, and VS12, so I can do whatever work I need, plus it has a variety of WinRT apps that I use on a regular basis (mostly the same apps as on the tablet).

I could use my tablet instead, but the Dell docking station for my laptop is somewhat more convenient than the docking station for the tablet. This is because I carry the tablet’s docking station with me everywhere. If I bought a second docking station to leave in my office then I’d probably just use the tablet instead of the laptop.

On the road

When I’m on the road there’s no access to a Natural keyboard, so I have wrist, arm, and shoulder pain. This is true with my laptop keyboard and the bluetooth tablet keyboard. They are both too small for me, but it isn’t realistic to carry a “real” keyboard around everywhere. So I put up with the pain and minimize the amount of typing work I do while traveling. Tai Chi helps too.

Over the past few months, I have taken to only carrying my tablet while on the road. Because I avoid doing extensive typing on the road, I also avoid doing extensive dev work. As a result, the difference between the i5 tablet and i7 laptop is pretty immaterial, and the tablet is a LOT lighter and easier to carry. It is also a lot more useful on the airplane (remember, I’m a big guy – even first class seats often have too little room to open my big laptop).

In short, while on the road, my tablet has become a complete laptop replacement.

At conferences

The one exception to the tablet replacing my laptop while on the road is when I go to conferences. The problem here isn’t probably what you’d expect: it is a video projection issue.

The tablet has HDMI out, and its docking station has HDMI out. No VGA out at all. I do have an HDMI to VGA converter (from HP) that usually works, but not always. If the sole purpose of my travel is to speak at a conference, you can imagine that it is bad if my computer can’t project onto the screen.

So I lug my laptop around specifically because it has a VGA output jack. Sad but true…

So in summary, once companies and conferences have a reliable way to project HDMI video content onto overhead screens, I’ll have no reason to carry my laptop at all anymore when on the road. And if I bought a second docking station to leave at my Magenic office I wouldn’t need my laptop there either – so I wouldn’t need the laptop at all.

The desktop is harder to give up because I’m a gamer, and there’s nothing on the horizon that would allow me to play my games on an affordable laptop, much less tablet.

Yes, laptops are doomed – tablets will replace them over the next few years – of that I have little doubt.

Desktops aren’t entirely doomed – at least for gamers, CAD users, people doing graphics work, and other scenarios where cost-effective high-end hardware is required. But even today few people have only a desktop. Most people have a desktop and laptop – and in the near future I expect they’ll have a desktop and tablet instead.

For me, I’m happy that my tablet is now my primary work machine. It works great, and meets my needs for everything except high end gaming.

Wednesday, July 11, 2012 12:25:10 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Tuesday, July 3, 2012

While the punditry and others are fixated on whether users can adapt to (or even enjoy) the new Windows Start screen and other new UX features, they are missing the real point of Windows 8 and WinRT.

A couple days ago my reasonably computer-savvy son wanted to do some art work, so he downloaded Paint .NET. Or so he thought.

These days most software for Windows is downloaded via the web. And any reasonably popular software has malicious clones with domain names, web sites, and even installers, that look similar to the real thing. This is absolutely the case with Paint .NET.

So my son downloaded what appeared to be a valid installer, from a domain name that seemed reasonable. And just like that his computer was infected with a bunch of Yahoo crap, along with a bunch of real spyware and malware. He’s still trying to get it all cleaned up.

I’ve done the same thing, and I’m extremely computer savvy. Sometimes even the most savvy user gets suckered by a very clever bad guy.

WinRT apps only come from a store. The Microsoft Store, or a corporate “store”.

To get into the Microsoft Store, developers must be registered, apps are screened by Microsoft, and if anything malicious does slip through, the app can be removed/revoked from the store.

To get into a corporate “store”, your employer must choose to put the app into that store. It seems unlikely that your IT department will put apps in their own store that they didn’t create or acquire from a known vendor.

As a result, you can imagine a “Paint WinRT” app that is like Paint .NET, but that my son would have found in the Microsoft Store, and installed from the Store. Effectively zero chance of all the spyware, malware, and Yahoo crap that comes with so much of today’s software.

Now think of all the PC users around the world who will be able to actually find and install software without the fear we all feel in today’s world.

Sure, Win8 and WinRT mean accepting some change. But personally I am entirely ready to embrace that change to get the benefits offered!

Tuesday, July 3, 2012 8:30:53 AM (Central Standard Time, UTC-06:00)  #    Disclaimer