Rockford Lhotka's Blog

Home | Lhotka.net | CSLA .NET

 Wednesday, September 28, 2011

Magenic is hosting a Code Mastery event in Atlanta on October 8, and I am one of the speakers.

This is a day of free CSLA 4 training, with content created and presented by people who use CSLA to build applications, and by people (Sergey and myself) who are instrumental in creating and maintaining the framework.

Sign up now, I suspect seats will go fast!

Wednesday, September 28, 2011 4:11:27 PM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [0]  | 

I have been giving quite a lot of thought to the WinRT migration path. What is the outlook for taking a Windows Forms, WPF, or Silverlight app into WinRT/Metro in Windows 8?

The amount of effort required for any given application may vary radically, depending on the architecture used when building the application, and how well that architecture was implemented in the actual code. And it is obviously important to understand how much client-side application code uses .NET features that aren’t in WinRT, or that are substantially different in WinRT.

And of course I tend to look at this from a CSLA .NET perspective Smile  If you use CSLA 4 today, and you adhere to the architecture and coding structures recommended when using CSLA, most or all of your business layer code will probably move to WinRT without change.

So, rather simplified, and CSLA-centric, here’s a set of process flows:

image

Although the first decision point is “Using CSLA?”, you could replace that with “using a architecture/framework that abstracts all business, validation, authorization, data access and other application logic away from the UI, exposing a model that supports data binding and async server interactions”. Although I’m obviously biased, there are absolutely other architectures that offer the same layered abstraction to keep all business and data logic out of the presentation layer. And that’s really what’s required.

In the final analysis, if you have any business or data logic in your code-behind, or you aren’t using data binding to connect your existing UI views to some sort of business objects, you have some work ahead of you to get to that point.

Essentially all non-CSLA Windows Forms apps I’ve ever seen will require a complete rewrite. Most use DataSet objects, and therefore require total rework. And most use a lot of code-behind, and therefore require total rework. And a lot of them use numerous windows and modal dialogs, so the user workflow will require a complete rethink.

A surprising number of WPF apps are written much like Windows Forms apps, with code-behind, etc. Those apps will require much the same effort to migrate as Windows Forms. But if you’ve written your WPF app using MVVM, even without something like CSLA, and have strictly avoided code-behind, the migration probably won’t be too bad.

The big thing is that a lot of WPF apps aren’t written to assume async server interactions, and updating code to handle that can be a lot of work. WPF apps written using CSLA may already be using the async features in CSLA, and so can avoid this issue entirely. Worst case, if you are already using CSLA synchronously, the changes to move to async aren’t overwhelming.

If you have a Silverlight app, you are in the best position of anyone, because you are already using async server interaction, and can’t have made the mistake of using the DataSet. And if you are using MVVM without any code-behind your migration will probably be quite smooth.

If you are also using CSLA, then your existing business layer will probably translate to WinRT without change.

As I mentioned in a previous WinRT post, Windows 8 is years away for most organizations. At the same time, I do think that WinRT/Metro will be used for business app development.

Quite a number of people are mistakenly saying that “Silverlight is dead”, when in reality Silverlight has never been more important.

What are you going to use to build business apps in the years between now and when Win8 is available in your organization?

You might consider using the technology that appears to offer the easiest migration to WinRT… And that is Silverlight (plus MVVM and CSLA 4 Smile ).

Wednesday, September 28, 2011 11:35:58 AM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [7]  | 
 Sunday, September 18, 2011

A number of people have asked about the future of CSLA .NET on WinRT (and Windows 8 and Metro).

(fwiw, you can always check out the CSLA roadmap to see what I’m planning)

The short answer is that (when Win8 comes out) I expect to have a CSLA 4 version 4.5 release that supports .NET 4.5, along with WinRT.

These are two different things.

.NET 4.5 builds apps that run on the Win8 desktop, not in Metro. I imagine .NET 4.5 will also support Win7, but I don’t know for sure. I was able to build the existing CSLA 4 version 4.2 code in .NET 4.5 without change. But I do expect that some changes will be required to take advantage of .NET 4.5 features.

For example, ASP.NET Web Forms is getting a major facelift in 4.5, as is ASP.NET MVC. It is reasonable to expect that CSLA will need to accommodate those changes – though the bulk of the impact should be in the Csla.Web and Csla.Web.Mvc projects.

Whether there are any interesting changes to WPF or Windows Forms is, at this point, something I haven’t explored.

WinRT is closer to Silverlight than full .NET, but it isn’t Silverlight either. I spent a couple hours this evening starting the port of CSLA 4 version 4.2 to WinRT.

  1. I started with the Csla.Silverlight project, because it is closest to what will work in WinRT
  2. I added the DataAnnotations implementation from Csla.Wp, because WinRT doesn’t have DataAnnotations
  3. WinRT is also missing both INotifyDataErrorInfo and IDataErrorInfo – so it isn’t clear how any validation errors can be reported to the UI from a business object (I hope they have some solution)
  4. I still need to add the WCF data portal service reference to the Csla.WinRT project, but it appears that the data portal is essentially the same as in SL

What remains are a couple relatively big issues that require some research:

  1. The BackgroundWorker component doesn’t exist in WinRT, and we’ll need to either rewrite it or switch everything to the new async/await model
  2. The .NET Type type is quite different in WinRT, so a lot of MethodCaller code needs to be changed to use the new WinRT type system

The MethodCaller issue is, I suspect, just a matter of learning and using the new type system. But this reveals an interesting fact: anyone using System.Reflection in their code (even for simple things) is probably going to need to make changes to move to WinRT.

The BackgroundWorker issue is more interesting. At first glance it seems obvious that we’d want to move to the async/await model. And I would – except that this model doesn’t exist in .NET 4, Silverlight 4, Silverlight 5, WP7, or WP7.5.

Silverlight 5 and WP7.5 are the challenges here, because they’ll be widely used concurrently with .NET 4.5 and WinRT over a period of months or years.

  1. If we require the use of async/await, then CSLA 4.5 could not support SL 5 or WP7.5 (this violates one of the key value statements of CSLA .NET)
  2. If we use async/await in .NET/WinRT, then you can’t have compatible object code between .NET/WinRT and SL/WP (this violates one of the key value statements of CSLA .NET)
  3. If we re-implement BackgroundWorker in WinRT, then CSLA and your business code is unaffected, but you won’t be able to use async/await when you interact with the async data portal or async business rules
  4. If we support the use of async/await on .NET/WinRT, but also support BackgroundWorker then you get to choose whether to write cross-compatible code, or code that works on 4.5/WinRT only

Clearly options 1 and 2 won’t work. So we have to explore re-implementing BackgroundWorker in WinRT. Presumably we’ll use async/await inside our BackgroundWorker replacement, but we’ll keep the external interface consistent. I hope this is possible – I’m just thinking out loud at this point.

In the medium timeframe option 4 has to be the goal. In the long run I think it is safe to assume that some future version of SL and some future version of Windows Phone will support async/await. When all the then-current Microsoft platforms support the model we’ll drop BackgroundWorker entirely.

Regardless, I am quite pleased by just how far I was able to get in just a couple hours work. I have the Csla.WinRT project structure in place, and have narrowed down the problem areas to:

  1. We need some validation error notification model to replace IDEI and INDEI
  2. We need a BackgroundWorker replacement
  3. We need a MethodCaller update

When you think about the breadth of scope of the CSLA 4 framework, I’m pretty amazed that we only have three problem areas to address for the core framework.

We’ll also need to create a Csla.Xaml.WinRT assembly with some UI helpers (that’s probably how we’ll solve the validation error issue for example). I haven’t explored how much of the existing Csla.Xaml concepts will carry forward – but I suspect Csla.Xaml.WinRT will be very much like the existing Csla.Xaml.Wp project.

Sunday, September 18, 2011 8:36:28 PM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [5]  | 
 Saturday, September 17, 2011

At //build/ this past week I heard numerous people suggest that WinRT and Metro aren’t going to be used for business app development. That Metro is for consumer apps only. These comments were from Microsoft and non-Microsoft people.

They could be right, but I think they are wrong.

Let’s think forward about 5 years, and assume that Win8 has become quite successful in the consumer space with Metro apps. And let’s remember that consumers are the same people who use computers in the corporate world.

Then let’s think back to the early 1990’s, when most corporate apps were 3270 or VT100 green-screen terminals, and what people used at home (or even at work for other apps like Lotus 123 or maybe Excel) was Windows.

Users back then pushed hard for Windows interfaces for everything. Compared to the green-screen terminals, Windows was a breath of fresh air, and users really wanted to get away from the terminal experience.

Metro is to today’s Windows, what Windows was to terminals. A smooth, touch-based interface that encourages more intuitive and aesthetically pleasing user experiences. And the extremely popular iPad interface is similar.

In 5 years I strongly suspect that users will be pushing hard for Metro interfaces for everything. The old-fashioned, legacy Windows look (because that’s what it will be) will be extremely undesirable.

In fact I would suggest it is already uncool, especially in the face of iPad apps that exist today.

Windows computers are … computers.

iPad devices are friendly companions on people’s individual journeys through life.

(and so are Windows Phone devices – my phone is not a computing device, it is an integral part of my life)

Windows 8 and Metro gives us the opportunity to build apps that fit into something that is an integral part of people’s lives.

Because most people spend at least half their waking life at work, it seems obvious that they’ll want their work apps to be just as smooth and seamless as all the other apps they use.

In short, my prediction is that 5 years from now there’ll be “legacy Windows developers” still building stuff that runs in the clunky desktop mode. And there’ll be “modern Windows developers” that build stuff that runs in Metro – and a lot of those Metro apps will be business applications.

Will we make Jensen (the Microsoft keynote speaker pushing the vision of Metro) happy with every one of these business apps? Will they all fit exactly into the “Metro style”?

I doubt it.

But games don’t either. Metro games take over the whole screen and do whatever they want in the space. And nobody complains that they break the Metro style rules.

Some data-heavy business apps will also break the Metro style rules – I pretty much guarantee it. And yet they’ll still run in the Metro mode, and thus will run on ARM as well as Intel chips, and won’t require the user to see the clunky desktop mode.

In 5 years we can all check back on this blog post to see if I’m right. But I strongly suspect that 5 years from now I’ll be having a great time building some cool Metro business app Smile

Saturday, September 17, 2011 10:52:48 AM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [9]  | 
 Friday, September 16, 2011

Microsoft revealed quite a lot of detail about "Windows 8" and its programming model at the //build/ conference in September 2011. The result is a lot of excitement, and a lot of fear and worry, on the part of Microsoft developers and customers.

From what I've seen so far, in reading tweets and other online discussions, is that people's fear and worry are misplaced. Not necessarily unwarranted, but misplaced.

There's a lot of worry that ".NET has no future" or "Silverlight has no future". These worries are, in my view, misplaced.

First, it is important to understand that the new WinRT (Windows Runtime) model that supports Win8 Metro style apps is accessible from .NET. Yes, you can also use C++, but I can't imagine a whole lot of people care. And you can use JavaScript, which is pretty cool.

But the important thing to understand is that WinRT is fully accessible from .NET. The model is quite similar to Silverlight for Windows Phone. You write a program using C# or VB, and that program runs within the CLR, and has access to a set of base class libraries (BCL) just like a .NET, Silverlight, or WP7 app today. Your program also has access to a large new namespace where you have access to all the WinRT types.

These WinRT types are the same ones used by C++ or JavaScript developers in WinRT. I think this is very cool, because it means that (for perhaps the first time ever) we'll be able to create truly first-class Windows applications in C#, without having to resort to C++ or p/invoke calls.

The BCL available to your Metro/WinRT app is restricted to things that are "safe" for a Metro app to use, and the BCL features don't duplicate what's provided by the WinRT objects. This means that some of your existing .NET code won't just compile in WinRT, because you might be using some .NET BCL features that are now found in WinRT, or that aren't deemed "safe" for a Metro app.

That is exactly like Silverlight and WP7 apps. The BCL features available in Silverlight or WP7 are also restricted to disallow things that aren't safe, or that make no sense in those environments.

In fact, from what I've seen so far, it looks like the WinRT BCL features are more comparable to Silverlight than anything else. So I strongly suspect that Silverlight apps will migrate to WinRT far more easily than any other type of app.

None of this gives me any real worry or concern. Yes, if you are a Windows Forms developer, and very possibly if you are a WPF developer, you'll have some real effort to migrate to WinRT, but it isn't like you have to learn everything new from scratch like we did moving from VB/COM to .NET. And if you are a Silverlight developer you'll probably have a pretty easy time, but there'll still be some real effort to migrate to WinRT.

If nothing else, we all need to go learn the WinRT API, which Microsoft said was around 1800 types.

So what should you worry about? In my view, the big thing about Win8 and Metro style apps is that these apps have a different lifetime and a different user experience model. The last time we underwent such a dramatic change in the way Windows apps worked was when we moved from Windows 3.1 (or Windows for Workgroups) to Windows 95.

To bring this home, let me share a story. When .NET was first coming out I was quite excited, and I was putting a lot of time into learning .NET. As a developer my world was turned upside down and I had to learn a whole new platform and tools and langauge - awesome!! :)

I was having a conversation with my mother, and she could tell I was having fun. She asked "so when will I see some of this new .NET on my computer?"

How do you answer that? Windows Forms, as different as it was from VB6, created apps that looked exactly the same. My mother saw exactly zero difference as a result of our massive move from VB/COM to .NET.

Kind of sad when you think about it. We learned a whole new programming platform so we could build apps that users couldn't distinguish from what we'd been doing before.

Windows 8 and Metro are the inverse. We don't really need to learn any new major platform or tools or languages. From a developer perspective this is exciting, but evolutionary. But from a user perspective everything is changing. When I next talk to my mother about how excited I am, I can tell her (actually I can show her thanks to the Samsung tablet - thank you Microsoft!) that she'll see new applications that are easier to learn, understand, and use.

This is wonderful!!

But from our perspective as developers, we are going to have to rethink and relearn how apps are designed at the user experience and user workflow level. And we are going to have to learn how to live within the new application lifecycle model where apps can suspend and then either resume or be silently terminated.

Instead of spending a lot of time angsting over whether the WinRT CLR or BCL is exactly like .NET/Silverlight/WP7, we should be angsting over the major impact of the application lifecycle and Metro style UX and Metro style navigation within each application.

OK, I don't honestly think we should have angst over that either. I think this is exciting, and challenging. If I wanted to live in a stable (stagnant?) world where I didn't need to think through such things, well, I think I'd be an accountant or something…

Yes, this will take some effort and some deep thinking. And it will absolutely impact how we build software over the next many years.

And this brings me to the question of timing. When should we care about Metro and WinRT? Here's a potential timeline, that I suspect is quite realistic based on watching Windows releases since 1990.

Win8 will probably RTM in time for hardware vendors to create, package, and deliver all sorts of machines for the 2012 holiday season. So probably somewhere between July and October 2012.

For consumer apps this means you might care about Win8 now, because you might want to make sure your cool app is in the Win8 online store for the 2012 holiday season.

For business apps the timing is quite different. Corporations roll out a new OS much later than consumers get it through retailers. As an example, Windows 7 has now been out for about three years, but most corporations still use Windows XP!!! I have no hard numbers, but I suspect Win7 is deployed in maybe 25% of corporations - after being available for three years.

That is pretty typical.

So for business apps, we can look at doing a reasonable amount of Win8 Metro development around 2015.

Yes, some of us will be lucky enough to work for "type A" companies that jump on new things as they come out, and we'll get to build Metro apps starting in late 2012.

Most of us work for "type B" companies, and they'll roll out a new OS after SP1 has been deployed by the "type A" companies - these are the companies that will deploy Win8 after has been out for 2-4 years.

Some unfortunate souls work for "type C" companies, and they'll roll out Win8 when Win7 loses support (so around 2018?). I used to work for a "type C" company, and that's a hard place to find yourself as a developer. Yet those companies do exist even today.

What does this all mean? It means that for a typical corporate or business developer, we have around 4 years from today before we're building WinRT apps.

The logical question to ask then (and you really should ask this question), is what do we do for the next 4 years??? How do we build software between now and when we get to use Metro/WinRT?

Obviously the concern is that if you build an app starting today, how do you protect that investment so you don't have to completely rewrite the app in 4 years?

I don't yet know the solid answer. We just don't have enough deep information yet. That'll change though, because we now have access to early Win8 builds and early tooling.

What I suspect is that the best way to mitigate risk will be to build apps today using Silverlight and the Silverlight navigation model (because that's also the model used in WinRT).

The BCL features available to a Silverlight app are closer to WinRT than full .NET is today, so the odds of using BCL features that won't be available to a Metro app is reduced.

Also, thinking through the user experience and user workflow from a Silverlight navigation perspective will get your overall application experience closer to what you'd do in a Metro style app - at least when compared to any workflow you'd have in Windows Forms. Certainly you can use WPF and also create a Silverlight-style navigation model, and that'd also be good.

Clearly any app that uses multiple windows or modal dialogs (or really any dialogs) will not migrate to Metro without some major rework.

The one remaining concern is the new run/suspend/resume/terminate application model. Even Silverlight doesn't use that model today - except on WP7. I think some thought needs to go into application design today to enable support for suspend in the future. I don't have a great answer right at the moment, but I know that I'll be thinking about it, because this is important to easing migrations in the future.

It is true that whatever XAML you use today won't move to WinRT unchanged. Well, I can't say that with certainty, but the reality is that WinRT exposes several powerful UI controls we don't have today. And any Metro style app will need to use those WinRT controls to fit seamlessly into the Win8 world.

My guess is that some of the third-party component vendors are well on their way to replicating the WinRT controls for Silverlight and WPF today. I surely hope so anyway. And that's probably going to be the best way to minimize the XAML migration. If we have access to controls today that are very similar to the WinRT controls of the future, then we can more easily streamline the eventual migration.

In summary, Windows 8, WinRT, and Metro are a big deal. But not in the way most people seem to think. The .NET/C#/CLR/BCL story is evolutionary and just isn't that big a deal. It is the user experience and application lifecycle story that will require the most thought and effort as we build software over the next several years.

Personally I'm thrilled! These are good challenges, and I very much look forward to building .NET applications that deeply integrate with Windows 8. Applications that I can point to and proudly say "I built that".

Update: here are a couple related blog posts from fellow Microsoft RDs:

and a good post from Doug Seven:

and from fellow Magenic experts:

Friday, September 16, 2011 8:27:24 PM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [17]  | 
On this page....
Search
Archives
Feed your aggregator (RSS 2.0)
October, 2014 (1)
August, 2014 (2)
July, 2014 (3)
June, 2014 (4)
May, 2014 (2)
April, 2014 (6)
March, 2014 (4)
February, 2014 (4)
January, 2014 (2)
December, 2013 (3)
October, 2013 (3)
August, 2013 (5)
July, 2013 (2)
May, 2013 (3)
April, 2013 (2)
March, 2013 (3)
February, 2013 (7)
January, 2013 (4)
December, 2012 (3)
November, 2012 (3)
October, 2012 (7)
September, 2012 (1)
August, 2012 (4)
July, 2012 (3)
June, 2012 (5)
May, 2012 (4)
April, 2012 (6)
March, 2012 (10)
February, 2012 (2)
January, 2012 (2)
December, 2011 (4)
November, 2011 (6)
October, 2011 (14)
September, 2011 (5)
August, 2011 (3)
June, 2011 (2)
May, 2011 (1)
April, 2011 (3)
March, 2011 (6)
February, 2011 (3)
January, 2011 (6)
December, 2010 (3)
November, 2010 (8)
October, 2010 (6)
September, 2010 (6)
August, 2010 (7)
July, 2010 (8)
June, 2010 (6)
May, 2010 (8)
April, 2010 (13)
March, 2010 (7)
February, 2010 (5)
January, 2010 (9)
December, 2009 (6)
November, 2009 (8)
October, 2009 (11)
September, 2009 (5)
August, 2009 (5)
July, 2009 (10)
June, 2009 (5)
May, 2009 (7)
April, 2009 (7)
March, 2009 (11)
February, 2009 (6)
January, 2009 (9)
December, 2008 (5)
November, 2008 (4)
October, 2008 (7)
September, 2008 (8)
August, 2008 (11)
July, 2008 (11)
June, 2008 (10)
May, 2008 (6)
April, 2008 (8)
March, 2008 (9)
February, 2008 (6)
January, 2008 (6)
December, 2007 (6)
November, 2007 (9)
October, 2007 (7)
September, 2007 (5)
August, 2007 (8)
July, 2007 (6)
June, 2007 (8)
May, 2007 (7)
April, 2007 (9)
March, 2007 (8)
February, 2007 (5)
January, 2007 (9)
December, 2006 (4)
November, 2006 (3)
October, 2006 (4)
September, 2006 (9)
August, 2006 (4)
July, 2006 (9)
June, 2006 (4)
May, 2006 (10)
April, 2006 (4)
March, 2006 (11)
February, 2006 (3)
January, 2006 (13)
December, 2005 (6)
November, 2005 (7)
October, 2005 (4)
September, 2005 (9)
August, 2005 (6)
July, 2005 (7)
June, 2005 (5)
May, 2005 (4)
April, 2005 (7)
March, 2005 (16)
February, 2005 (17)
January, 2005 (17)
December, 2004 (13)
November, 2004 (7)
October, 2004 (14)
September, 2004 (11)
August, 2004 (7)
July, 2004 (3)
June, 2004 (6)
May, 2004 (3)
April, 2004 (2)
March, 2004 (1)
February, 2004 (5)
Categories
About

Powered by: newtelligence dasBlog 2.0.7226.0

Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

© Copyright 2014, Marimer LLC

Send mail to the author(s) E-mail



Sign In