Rockford Lhotka's Blog

Home | | CSLA .NET

 Thursday, 08 January 2015
LVSPK20 Visual Studio Live is coming to Las Vegas March 16-20. Modern Apps Live is co-hosted for the same dates/location, and registering for either event gets you access to both – good deal!

Great content on web, windows, and mobile development, including coverage of the service, cloud, and data technologies you need to make those apps really sing.

Save $500 by registering via this link: LVSPK20REG

Thursday, 08 January 2015 17:34:54 (Central Standard Time, UTC-06:00)  #    Disclaimer
 Friday, 24 October 2014

CSLA .NET predates the MVVM pattern by around a decade. All that time I've been telling people they should create an object model that matches the problem domain. Lots of people told me I was talking about "old fashioned OO" or otherwise dismissed what I was saying. They preferred to think of their 'model' as simple data container objects.

At some point most of them eventually realized that they needed something that actually matched the problem domain, and that their 'model' couldn't do it while still being simple data containers.

So they invented a new concept called a 'viewmodel' that (when done right) does match the problem domain - just like the UI always matches the problem domain.

At this point if you are a CSLA user you encounter an interesting situation, where you've been creating domain objects maybe for a decade longer than MVVM has existed, but MVVM is now the POTY (pattern of the year) and so you feel like you need to use it. Everyone wants the POTY after all :)

I spent a lot of time thinking about this and eventually decided that creating a viewmodel that echoes all your domain object's properties is just a lot of busy-work that has huge cost in development and testing. So it is _far_ better for your 'viewmodel' to just expose your preexisting CSLA domain objects to the UI, because THAT IS WHAT THEY ARE DESIGNED FOR.

Now it turns out that the MVVM pattern does have one thing CSLA doesn't have: the concept that the viewmodel implements UI-specific verbs (methods).

A good CSLA model is UI-neutral and so doesn't include methods for things like navigation or displaying error messages. A good viewmodel _does_ have methods that do those things through the use of an MVVM framework so those methods aren't implemented in a way that tightly couples the viewmodel to the UI technology.

Given that, combining CSLA with MVVM means that you need a viewmodel that exposes your CSLA domain objects to the UI, and that implements UI-specific methods to manage user interaction.

In the simple case what you need is a viewmodel class that exposes a single Model property, and then you can implement your UI handler methods. That's what ViewModelBase does for you.

In a lot of more complex scenarios you'll need a viewmodel that exposes multiple CSLA model objects - in which case you can learn from the way ViewModelBase is implemented and leverage that knowledge to create your own viewmodels. In any case though, the viewmodels implement properties to expose the CSLA domain objects to the UI and also implement methods that handle UI-specific requirements. The viewmodels shouldn’t be echoing the existing CSLA domain properties to the UI, because that’s just a waste of time, effort, and money.

Friday, 24 October 2014 12:21:06 (Central Standard Time, UTC-06:00)  #    Disclaimer
 Tuesday, 05 August 2014


Registration for Live! 360 Orlando is now open.

The conference is in Orlando, November 17-21, 2014.

I am co-chair for Visual Studio Live! and chair of Modern Apps Live! The event also includes SQL Server Live! and SharePoint Live! and TechMentor, meaning that Live! 360 covers all your development and IT pro training needs.

Visual Studio Live! covers .NET, web, and JavaScript development topics. Everything you need to know about single page apps, ASP.NET, Web API, and .NET can be found here.

Modern Apps Live! covers all modern development topics, including iOS, Android, Windows 8, SPAs, Azure, business intelligence, agile SDLC, git, Xamarin, and more. Modern Apps Live! is a unique conference in that it consists of 5 days of content that provides a single narrative, more like 5 days of training than a traditional conference.

Personally I’ll be co-presenting a pre-conference workshop on the use of C# for cross-platform development using .NET and Xamarin. And I’ll be giving talks as part of Modern Apps Live! and Visual Studio Live!

This is going to be a great conference, register now for the best pricing! (using the link in this blog post saves you $600)

Tuesday, 05 August 2014 10:46:52 (Central Standard Time, UTC-06:00)  #    Disclaimer
 Monday, 04 August 2014

magenic black square 143 As long-time readers of my blog know, I’ve worked for Magenic for along time – 14 years actually.

Who in our industry works for one company for that long? In my view this goes to show how good a company Magenic is as an employer.

Are you a .NET developer? If so, you are probably employed. Still, wouldn’t it be cool to work at a company like Magenic?

We are specifically recruiting for our Atlanta, Boston, Chicago, and San Francisco offices. If you are in SoCal or the Twin Cities we’re looking for good .NET and iOS developers there too.

And we have a traveling group, so if you live anywhere else and enjoy traveling elsewhere in the country we’d love to talk to you.

Monday, 04 August 2014 12:05:36 (Central Standard Time, UTC-06:00)  #    Disclaimer
 Saturday, 26 July 2014

I am sitting here listening to Stone Sour on Xbox Music (yes, I’m a hard rock/metal fan – always have been).

Stone Sour - what an excellent band. Not only because their music rocks, but because their stage performance is amazing. If you ever have the chance I suggest you see them in concert. Don’t bother to go out of your way to see Rob Zombie. His music might be good, but he is flakey and might skip out on a live show in the middle.

I say this because I was just at Rock Fest in Cadott, WI and that’s what happened. Stone Sour, despite the Corey Taylor having a rough throat put on an amazing performance – Corey gave everything he had left to put on a great show. Yes, it was sub-standard in terms of his voice, but it was perhaps the most amazing show I’ve ever seen.

Rob Zombie, having a rough throat, did just enough to get paid and then walked off the stage, unwilling to match Stone Sour’s ability to put everything into the performance. Rob Zombie said, in so many words, that he was willing to walk off stage rather than give a sub-standard performance, missing the opportunity to match Taylor’s dedication to his audience.

There’s a parallel to software development that crystallized for me with these two contrasting performances. It is something I think my friend Billy Hollis has been trying to tell me (and the rest of the industry) for the past few years.

When we’re younger we’re so ready to prove ourselves that we’ll do pretty much whatever it takes to get the job done – to build software that meets the user’s needs. It seems that many of us change as we get older, being more willing to abandon the user’s needs in our pursuit of “doing the right thing”. We focus on TDD and Agile and all sorts of other esoteric concepts at the expense of actually getting things done for the users who need our software to improve their lives.

Don’t get me wrong, I’m not saying we should write crappy software. But  there’s a mantra in Microsoft that applies here: “shipping is a feature”. In other words, if you delay getting sh*t done because you’ll only release if your code is perfect then you are missing the whole point of writing software. We aren’t creating art, we’re improving people’s lives – which can only be done by putting our software in the hands of actual users.

There’s a balance to be struck between “doing everything right” and “getting sht*t done”. For most of my career I’ve leaned toward the latter, but it is true that as I’ve gotten older I’ve put a higher value on the former.

Thinking about this, I think it is the same misguided ego that caused Rob Zombie to piss off a couple thousand fans by walking off stage. Exactly the opposite of Corey Taylor who got sh*t done even if it wasn’t perfect – and thus won the love of a couple thousand of the same fans.

I’ll go out of my way to see Stone Sour again, but I if I see Rob Zombie it will be because he came to me – I’ll never bother to pay to watch him walk off stage again.

I suspect the same is true with the users of our software. If we actually release something – even if if isn’t perfect – our users will be happier than if we get halfway through a project and fail because we were so focused on making it perfect that it couldn’t be accomplished with reasonable effort.

In summary, things like Agile and TDD are great, as long as they don’t get in the way of getting sh*t done.

Saturday, 26 July 2014 01:03:38 (Central Standard Time, UTC-06:00)  #    Disclaimer
 Monday, 14 July 2014

From around 1995 until 2010 there was really only one operating system for client computing: Windows.

Prior to 1995 there were a lot of options, though most not recognizable to users today: 3270 terminals, VT terminals, OS/2, Windows, DOS, CPM, and a bunch of others. Now most of these weren’t “client computing”, they were relatively dumb terminal technologies that provided access to a server (back then called a mainframe or minicomputer). Very much like today’s web browser (sans JavaScript).

Today we’ve returned to a chaotic landscape of client computing: browsers, Windows, iOS, OS X, Android, Linux (for the daring), and of course it isn’t like the pre-1995 technologies went away, they are just mostly emulated in Windows. What is interesting though, is that most of today’s client computing technologies do actually enable smart client software development. This includes the browser which can be used as a smart client technology via JavaScript development, even though the majority of browser “apps” are actually just colorful versions of 1990-era terminal-based computing where the processing is all on a server/mainframe/minicomputer/whatever-you-want-to-call-it.

What is interesting about this return to client-side chaos is that it has reopened the door for third party developer tools as a niche market.

In the early 1990’s there were quite a number of companies selling developer tools for other company’s platforms. Borland with C++, Delphi and TurboPascal, Gupta with SqlWindows, Powerbuilder, and a lot more.

When Windows became the dominant client computing platform most of these dev tools fell by the wayside (not that they went away, they just stopped being mainstream). This was because they couldn’t compete with Microsoft’s dev tools, which were always in sync with the platform in a way that was probably too expensive for third parties to match.

I think it is notable that our return to client computing chaos (or pluralism?) today has already led to numerous third party dev tool vendors that sell dev tools for other company’s platforms. Xamarin, PhoneGap, Telerik’s tools, and a lot more.

What is different to me is that in the early 1990’s I thought it was pretty obvious that Windows would become a dominant platform, and I tended to argue against using third party dev tools because I thought they’d have a rough go of it. As cool as Delphi was, I always recommended VB.

Today I’m not so sure. I don’t see any of today’s platforms becoming dominant in the foreseeable future. It is hard to imagine Windows returning to its monopoly status, but I can’t imagine iOS or Android or OS X displacing Windows as the primary corporate desktop computing environment either.

As a result we business developers need some way to build software independently of any particular platform or OS vendor, because we must assume all our business software will need to run on multiple platforms and OSes.

So today I find myself in the inverse of my early 1990’s stance, in that I’m reasonably convinced that building smart client software (at least for business) means using third party dev tools from vendors that aren’t tied to any one platform.

Of course I’ve spent the last 14 years in the .NET world, so naturally I gravitate toward a combination of Xamarin and Microsoft .NET as a way to use my C# and .NET knowledge across all platforms. I get to develop in Visual Studio on Windows where I’m most comfortable, and my resulting software runs on Android and iOS as well as on Windows Desktop, Phone, and WinRT.

As far into the future as I can see there’s no obvious platform/OS “winner”, so as a developer the question isn’t which platform to target, it is which third party dev tool reaches all platforms with a solid strategy that will stand out and thrive over the next many years.

Monday, 14 July 2014 13:00:31 (Central Standard Time, UTC-06:00)  #    Disclaimer
 Tuesday, 01 July 2014

There’s been a lot of exciting change in cross-platform development for C# developers over the past few months. Microsoft introduced the Universal Apps concept for WinRT (Windows 8 and Windows Phone 8.1), and Xamarin introduced Xamarin.Forms (Windows Phone 8, Android, and iOS).

Beneath the Universal App support in Visual Studio 2013 is a broader concept called a Shared Project. With the Shared Project Reference Manager add-in for VS13 you can reference these shared projects from any project, not just Universal App projects.

As a result, you can build a solution like this one:


This solution includes a Xamarin.Forms MobileApp, a Microsoft Universal App (based on the Hub control), a Windows Forms app, and a WPF app. All of these apps use non-UI code from the NonUICode.Shared project.

In fact, the Android, iOS, WinPhone, Windows, and WindowsPhone UI projects have basically no code at all. In the MobileApp all the UI code is in the MobileApp1.Shared project. In the WinRTApp all the UI code is in the HubApp1.Shared project.

The Windows Forms and WPF apps each have their own UI code. Windows Forms is its own thing, and although WPF uses XAML, it is an older dialect that doesn’t share enough in common with WinRT or Xamarin.Forms for sharing.

None of the UI projects contain any business logic or logic to call services. All that code is in the NonUICode.Shared project so it can be maintained just one time. The service calls use HttpClient, which is reasonably common across all the UI platforms, and for the few differences I’m using #if statements to accommodate the per-platform code. For example, here’s a bit of code from a shared viewmodel class: 

    public async Task SaveData()
      if (this.IsDataLoaded)
        var webClient = new HttpClient();
        var data = JsonConvert.SerializeObject(this.Speaker);
#if ANDROID || __ANDROID__ || __IOS__
        var content = new StringContent(data, System.Text.Encoding.UTF8, "application/json");
        var content = new HttpStringContent(data);
        var urlString = apiSpeakerUrl + @"/" + this.Speaker.Id.ToString();
        var response = await webClient.PutAsync(new Uri(urlString), content);
        if (!response.IsSuccessStatusCode)
          throw new Exception("SaveData failed");

The overall result is that with reasonable effort you can create an app that spans every type of smart client technology available today; from Windows Forms up to iOS. These apps can share all your business and service client code, and can often share a lot of UI code.

(fwiw, if you build your business logic with CSLA .NET it is a lot easier to create and maintain the shared business and service client code than if you try to build that code by hand)

CSLA .NET | WinRT | WP8 | Xamarin
Tuesday, 01 July 2014 15:32:53 (Central Standard Time, UTC-06:00)  #    Disclaimer
 Wednesday, 18 June 2014

A couple of us at Magenic have been spending some time looking into the new Xamarin.Forms technology.


It has some nice potential, but is clearly at the prototype stage more than the ready-for-use stage.

The good potential centers around the start of a XAML dialect they’ve created that describes common UI elements and concepts across iOS, Android, and Windows Phone 8 (Silverlight). Using this dialect you can’t get at all the features of each platform, but you can get at enough features to create standard data entry and data viewing forms like you’d need for a typical business application. And there’s always an easy escape hatch that allows you to build per-platform forms for when a common form just isn’t enough.

The bad points are areas I hope they’ll address soon so the technology becomes more useful for real work.

The first roadblock is the almost complete lack of documentation or samples showing how to use their XAML dialect. They have samples showing how to build forms in C#, but not in XAML. It reminds me of the first few months when Microsoft introduced XAML for WPF.

Perhaps it is because of the lack of XAML samples/docs, but it is a real struggle to figure out how to do things like async loading of data, full implementations of data binding against standard data binding types, etc.

I think this whole thing has potential. WPF was really rough when it was introduced, and eventually Microsoft improved the docs and samples and designer tools. And they eventually smoothed over the most egregious data binding issues, allowing the vast majority of existing .NET types to bind into WPF.

I really hope Xamarin does the same thing with this technology.

Wednesday, 18 June 2014 21:45:08 (Central Standard Time, UTC-06:00)  #    Disclaimer
On this page....
Feed your aggregator (RSS 2.0)
November, 2017 (2)
October, 2017 (1)
September, 2017 (3)
August, 2017 (1)
July, 2017 (1)
June, 2017 (1)
May, 2017 (1)
April, 2017 (2)
March, 2017 (1)
February, 2017 (2)
January, 2017 (2)
December, 2016 (5)
November, 2016 (2)
August, 2016 (4)
July, 2016 (2)
June, 2016 (4)
May, 2016 (3)
April, 2016 (4)
March, 2016 (1)
February, 2016 (7)
January, 2016 (4)
December, 2015 (4)
November, 2015 (2)
October, 2015 (2)
September, 2015 (3)
August, 2015 (3)
July, 2015 (2)
June, 2015 (2)
May, 2015 (1)
February, 2015 (1)
January, 2015 (1)
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)

Powered by: newtelligence dasBlog 2.0.7226.0

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

© Copyright 2017, Marimer LLC

Send mail to the author(s) E-mail

Sign In