Rockford Lhotka

 Monday, July 19, 2010

I was just at a family reunion and heard a joke about the comedian’s retirement home. A guy walks into the common room and hears one old guy shout out “19”, and everyone laughs. Across the room another guy shouts out “54” and everyone laughs even harder. The guy turns to his guide and asks “What is going on?”. The guide replies “These guys know all the same jokes, and at their age it takes too long to tell them, so they just assigned them all numbers.” The guy smiles, and shouts out “92”, which results in a just a few grudging chuckles. “What’d I do wrong?” he asks the guide. The guide replies “Some people can tell a joke, some people can’t.”

That made me think about patterns (yes, I know, I’m a geek).

I like design patterns. Who wouldn’t? They are a formalized description of a solution to a specific problem. If you have that problem, then having a formally described solution seems like a dream come true.

Perhaps more importantly patterns are a language short-cut. If everyone in a conversation understands a pattern, the pattern (and often its problem) can be discussed merely by using the pattern name, which saves an immense amount of time as opposed to describing the actual problem and solution in detail.

Of course the “formalized description” is prose. Human language. And therefore it is ambiguous and open to interpretation. The descriptions must be human-readable, because any pattern worth ink and paper transcends any specific platform or programming language. Describing a “pattern” in Java or C# is silly – because that makes it far too likely that it isn’t really a broad pattern, but is simply a practice that happens to work in a given language or on a given platform.

But this ambiguity leads to trouble. Not unlike the comedian’s retirement home, patterns are a short-cut language to some really complex concepts, and often even more complex implementations. While everyone might have a basic comprehension of “inversion of control”, I can guarantee you that saying IoC doesn’t bring the same concept, implementation or emotional response from everyone who hears it.

Pattern zealots often forget (or overlook) the fact that patterns have consequences. Good and bad consequences. Every pattern has bad consequences, as well as good ones. Some people get attached to a pattern because it helped them at some point, and they just assume that pattern will always have a positive or beneficial result. But that’s simply not true. Sometimes the negative consequences of a pattern outweigh the positive – it is all very dependent on the specific problem domain and environment.

Soft things like staffing levels, skill sets, attitudes and time frames all enter into the real world environment. Add the reality that any given problem almost certainly has several patterns that provide solutions – for different variations of the problem – and it becomes clear that no one pattern is always “good”.

It should come as no surprise then, that patterns are often misused – in several different ways.

My pet peeve is when a pattern is applied because something likes the pattern, not because the application actually has the problem the pattern would solve. I often see people using IoC, for example, because it is trendy, not because they actually need the flexibility provided by the pattern. They use a container to create instances of objects that they will never swap out for other implementations. What a waste – they’ve accepted all the negative consequences of the pattern for absolutely no benefit since they don’t have the problem the pattern would solve. Is this the fault of IoC? Of course not, IoC is a powerful pattern.

It is the fault of what I call the “Pattern Of The Year” (POTY) syndrome. When a pattern becomes really popular and trendy, it becomes the POTY. And everyone wants to go to the POTY. If you need the POTY, you should go. But if you don’t need the POTY, it is really a little silly (if not creepy) for you to go to the POTY…

In short: only use a pattern if you have the problem it solves, and the positive consequences outweigh the negative consequences.

Perhaps the most common misuse of patterns is failure to actually understand the pattern or its implementation. To stick with IoC as an example, it is pretty common for a development team to completely misunderstand the pattern or the framework that implements the pattern. Sure, some architect or lead developer “got it” (or so we hope) which is why the team is using the pattern – but you can find apps where numerous competing containers are created, each initialized differently.

I always thought Apple BASIC spaghetti code was the worst thing possible – but misuse of certain design patterns quickly creates a mess that is an order of magnitude worse than anything people wrote back in the early 80’s…

In short: if you use a pattern, make sure your entire team understand the pattern and your implementation of the pattern.

As I mentioned earlier, most problems can be solved by more than one pattern. Any truly interesting problem almost certainly has multiple solutions, each with different good/bad consequences and various subtle differences in outcome. It is not uncommon for the best solution to be a combination of a few more basic patterns.

As an example, the CSLA data portal is a combination of around six basic design patterns that work together in concert to solve the problem space the data portal targets. I’m not saying the data portal is a design pattern, but it is a solution for a problem that came into being by combining several complimentary patterns.

A few years after I created the data portal, various other design patterns were formalized that describe other solutions to this same problem space. Some are similar, some are not. If you look into each solution, it is clear that each one is actually a different combination of some lower level design patterns, working together to solve the problem.

The thing is, every pattern your bring into your solution (or ever pattern brought in by a higher level pattern) comes with its own consequences. You need to be careful to minimize the negative consequences of all those patterns so the overall balance is toward the positive.

In short: don’t be afraid to combine simple or basic design patterns together to solve a bigger problem, but be aware of the negative consequences of every pattern you bring into play.

Having introduced this concept of “low level” vs “high level” patterns, I’m going to follow that a bit further. Most of the patterns in the original GoF book are what I’d call low level patterns. They stand alone and have little or no dependency on each other. Each one solves a very narrow and clear problem and has very clear good/bad consequences.

Of course that was 15 years ago, and since then people have applied the pattern concept to more complex and bigger problem spaces. The resulting solutions (patterns) very often build on other patterns. In other words we’re raising the level of abstraction by building on previous abstractions. And that’s a fine thing.

But it is really important to understand that ultimately patterns are implemented, and the implementations of patterns are often far messier than the abstract though models provided by the patterns themselves. Even that is OK, but there’s a meta-consequence the flows out of this: complexity.

As you start to use higher level patterns, and their implementations, you can easily become locked into not only the implementation of the pattern you wanted, but also the implementations of the lower level patterns on which the implementation is built.

Again I’ll use IoC to illustrate my point. If you want IoC you’ll almost certainly use a pre-existing implementation. And once you pick that framework, you are stuck with it. You won’t want to use more than one IoC framework, because then you’d have multiple containers, each configured differently and each competing for the attention of every developer. The result is a massive increase in complexity, which means a reduction in maintainability and a corresponding increase in cost.

Now suppose you pick some higher level pattern, perhaps a portal or gateway, that is implemented using IoC. If you want the implementation of the gateway pattern you must also accept a dependency on their IoC framework choice.

People often ask me whether (or when will) CSLA .NET will incorporate Enterprise Library, log4net, Unity, Castle/Windsor, <insert your framework here>. I try very, very, very hard to avoid any such dependencies, because as soon as I pick any one of these, I make life really hard for everyone out there who didn’t choose that other framework.

CSLA 3.8 has a dependency on a simple data structure framework, and even that was a continual nightmare. I can hardly express how happy I am that I was able to get rid of that dependency for CSLA 4. Not that the data structure framework was bad – it does a great job – but the complexity introduced by the dependency was just nasty.

In short: be aware of the complexity introduced as high level patterns force you to accept dependencies on lower level patterns and implementations.

The final topic I’d like to cover flows from a conversation I had with Ward Cunningham a few years ago. We were talking about patterns and the “pattern movement”, and how it has become a little warped over time as people actively look for ways to apply patterns, rather than the patterns being used because they are the natural answer to a problem.

It is kind of like a carpenter who spends a lot of money buying some really nice new power tool. And then trying to use that power tool for every part of the construction process – even if that means being less efficient or increasing the complexity of the job – just to use the tool.

Obviously I’d never want to hire such a carpenter to work on my house!!

Yet I’ve seen developers and architects get so fascinated by specific patterns, frameworks or technologies that they do exactly that: increase the complexity of simple problem domains specifically so they can use their new toy concept.

In this conversation Ward suggested that there are different levels of understanding or mastery of patterns. At the most basic level are people just learning what patterns are, followed by people who “get” a pattern and actively seek opportunities to use that pattern. But at higher levels of mastery are people who just do their job and (often without a conscious thought) apply patterns as necessary.

Carpenters don’t think twice about when and how to construct a staircase or put together a 2x6” wall frame. These are common design patterns, but they are natural solutions to common problems.

In short: strive for “pattern mastery” where you are not fixated on the pattern, but instead are just solving problems with natural solutions, such that the pattern “disappears” into the fabric of the overall solution.

The pattern movement has been going on for at least 15 years in our industry. And over that time I think it has been far more beneficial than destructive.

But that doesn’t mean (especially as a consultant) that you don’t walk into many organizations and see horrible misuse of design patterns – the results being higher complexity, lower maintainability and higher cost of development and maintenance.

I think it is important that we continually strive to make patterns be a common abstract language for complex problems and solutions. And I think it is important that we continually educate everyone on development teams about the patterns and implementations we bring into our applications.

But most importantly, I think we need to always make conscious choices, not choices based on trends or fads or because somebody on the team is in love with pattern X or framework Y or technology Z.

  1. Use a pattern because you have the problem it solves
  2. Only use a pattern if the good consequences outweigh the bad (and remember that every pattern has negative consequences)
  3. Use patterns and implementations only if the entire team understands them
  4. Use the simplest pattern that solves your problem
  5. Don’t be afraid to combine several simple patterns to solve a complex problem
  6. Be aware of (and consciously accept) the consequences of any low level patterns that come with most high level pattern implementations
  7. Strive for “pattern mastery”, where you are solving problems with natural solutions, not looking for ways to apply any specific pattern

Eventually maybe we’ll all be in a software development retirement home and we can shout things like “Memento” and “Channel adaptor” and everyone will chuckle with fond memories of how those patterns made our lives easier as we built the software on which the world runs.

Monday, July 19, 2010 11:03:04 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Tuesday, July 13, 2010

I have put the CSLA 4 MVVM video series on the store:

http://store.lhotka.net/Default.aspx?tabid=1560&ProductID=21

The video series is not complete, but the first two segments are online.

The current $44.95 $74.95 purchase price is a limited time offer - a discount from the final price (to be determined) for people willing to buy now and get the rest of the content as it is completed.

I expect to complete the series by the end of July, so if you want the discount please act soon.

Tuesday, July 13, 2010 8:45:07 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Thursday, July 8, 2010

CSLA 4 release candidate 0 is now available for download from http://www.lhotka.net/cslanet/download.aspx

We are rapidly closing in on the final release of CSLA 4 with support for .NET 4, Silverlight 4 and Visual Studio 2010. This is primarily a bug fix release, and should be very stable.

There are a couple new enhancements to the ASP.NET MVC support, and a handful of bug fixes focused primarily on XAML data binding and the new business rules system.

Assuming no major issues are discovered in this release candidate in the next week or so, I expect CSLA 4 to release around July 19.

Thursday, July 8, 2010 9:12:21 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Thursday, July 1, 2010

The fact that server access is all async in Silverlight makes some common tasks a little more challenging. This includes lazy loading child objects in an on-demand manner.

When implementing lazy loading in CSLA it is pretty typical to implement the on-demand load of the child property value in the child property getter. In other words, in the parent object, there’ll be a property that exposes the child object, and in the getter of that property is where the lazy loading code goes:

public static PropertyInfo<Child> ChildProperty = RegisterProperty<Child>(c => c.Child);
public Child Child
{
  get
  {
    if (!FieldManager.FieldExists(ChildProperty))
    {
      Child = DataPortal.Fetch<ChildLoader>().Child;
      OnPropertyChanged(ChildProperty);
    }
    return GetProperty(ChildProperty);
  }
  private set { LoadProperty(ChildrenProperty, value); }
}

The ChildLoader type shown here is a command object (I typically use a ReadOnlyBase subclass) that runs to the server, loads the child object and returns it to the client. ChildLoader might look like this:

[Serializable]
public class ChildLoader : ReadOnlyBase<ChildLoader>
{
  public static PropertyInfo<Child> ChildProperty = RegisterProperty<Child>(c => c.Child);
  public Child Child
  {
    get { return ReadProperty(ChildProperty); }
    private set { LoadProperty(ChildProperty, value); }
  }

  private void DataPortal_Fetch()
  {
    Child = DataPortal.FetchChild<Child>();
  }
}

This all works great in .NET, where all this code is synchronous. But it needs a little tweaking to work in Silverlight, where server communication is async.

First, the parent property getter must return something before it has the actual value. This is kind of a big deal, because it means the UI must be able to handle getting back a null value, and then later getting the real value. This isn’t too hard though, at least if you are using data binding, because the UI will show nothing for the null value, and will automatically refresh the display when the real value arrives (because CSLA will raise a PropertyChanged event for the Child property).

Also, you’ll probably want to mark the parent object as busy while the operation is occurring, so the UI can take appropriate steps (again, by using data binding against the IsBusy property) to block the user from trying to interact with this part of the app until the actual data arrives:

public static PropertyInfo<Child> ChildProperty = RegisterProperty<Child>(c => c.Child);
public Child Child
{
  get
  {
    if (!FieldManager.FieldExists(ChildProperty))
    {
      MarkBusy();
      DataPortal.BeginFetch<ChildLoader>((o, e) =>
        {
          if (e.Error != null)
            throw e.Error;
          Child = e.Object.Child;
          MarkIdle();
          OnPropertyChanged(ChildProperty);
        });
    }
    return GetProperty(ChildrenProperty);
  }
  private set { LoadProperty(ChildrenProperty, value); }
}

When the getter is first called it will start the async load operation, and then it will return null. Later, when the BeginFetch() call completes it will set the Child property to the actual value and indicate that the parent object is no longer busy.

The ChildLoader is unaffected, since it was (and still is) running primarily on the .NET app server. The only difference is that the client is using BeginFetch() instead of Fetch(), so the ChildLoader is running async instead of sync. But that doesn’t affect the way ChildLoader works – so the only impact is to the parent object’s Child property getter.

Thursday, July 1, 2010 12:11:43 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Tuesday, June 29, 2010

CSLA includes a control called PropertyStatus, which is somewhat like the Windows Forms ErrorProvider, but far more powerful. It displays error, warning and informational messages from the business object property to which it is bound, and also exposes various metadata properties so other UI elements can bind in interesting ways (like disabling or hiding parts of the UI if the user isn’t authorized to view or edit a property).

The PropertyStatus control has been around for a couple years, in Silverlight 2 and 3 and WPF 3.5.

It broke in Silverlight 4 (but not WPF 4). I spent most of today trying to figure out why. What changed? We’d made a few changes to the control as part of the CSLA 4 project, but nothing really major – certainly nothing that seemed like it should make the control fail in SL4 and work in WPF (it is the same control for both technologies).

After a couple hours of frustration with the debugger, I enlisted the help of my friend and colleague Justin Chase. We fired up SharedView and spent a couple more hours of quality time with the VS10 debugger.

Nothing made sense. The problem was that the control would just disappear. If it was displaying an error icon, and the property was changed, but remained in error, the icon would disappear – the control would vanish.

The control is written using the VisualStateManager (VSM). So whether it is visible or not depends on which visual state is current. States are Valid, Error, Warning, Information, Busy.

There’s exactly one line of code in the control that calls the VMS GoToState() method. We could watch the code set the visual state to Error. And then we could watch the control vanish from the UI shortly thereafter.

Justin had the bright idea to put non-blank content in the Valid and Busy states (because normally they are empty). That worked – it turned out that something was setting the state to Valid.

We searched rather thoroughly through the CSLA codebase trying to find anything that might be using the VSM to set the state to Valid. We commented out most of the code in the control – including the one GoToState() call. We made sure CSLA was not setting the visual state.

And yet the state was being set to Valid.

So we changed the name of the state from Valid to Foo. That fixed the problem. Whatever code (presumably in the Silverlight runtime???) that was setting the state to Valid was no longer impacting us, because we no longer had a Valid state.

I assume this has something to do with the new validation concepts built into Silverlight 4. But talk about nasty! Apparently something in Silverlight runs through the visual tree, setting visual states of controls to “Valid” if that state is defined. I rather suspect there are other “reserved states” as well – but I don’t know for sure.

Of course my theory could be wrong, and perhaps it is yet something else that is setting visual states to Valid – but my money is on the Silverlight 4 validation system…

This is a horrific breaking change from SL3 to SL4, primarily because it isn’t something you’d expect. To have some other code hijack your visual states just because of how they are named – that’s really unpleasant.

So I’m blogging this in the hopes that anyone else using the VSM with a state name of “Valid” can avoid spending as many hours as Justin and I just did trying to figure out the problem…

Tuesday, June 29, 2010 2:58:25 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Friday, June 25, 2010

CSLA 4 beta 3 is now available for download.

This is the final beta release of CSLA 4. All work going forward will be focused on stabilization, bug fixing and updating sample applications. My current plan is to do a release candidate the week of July 5, and final release around July 15.

New features include:

  • Improved ASP.NET MVC 2 support
  • Server exceptions can be altered by your IDataPortalExecptionInspector implementation
  • ERLB now has a default AddNewCore() implementation
  • Numerous other bug fixes and minor tweaks based on user feedback

As always, see the change log for a list of important changes in this release.

Given the short timeline until release, it is really important that anyone considering using CSLA 4 in the near future help out by using the framework and identifying any bugs or stability issues. In short, I need your help to make this a successful release.

Thank you!

Friday, June 25, 2010 11:30:18 AM (Central Standard Time, UTC-06:00)  #    Disclaimer

CSLA .NET 3.8.4 is now available as a beta download. This is mostly a bug fix release to address a few issues from 3.8.3, plus some ASP.NET MVC work.

Version 3.8.4 targets .NET 3.5 and Silverlight 3 (though with a little effort it works with Silverlight 4 as well).

See the change log for a list of changes. There aren’t many, but if they affect you then they are important.

The only feature change in 3.8.4 is that most of the new ASP.NET MVC 2 support from CSLA 4 has been back-ported to 3.8. This means that the Csla.Web.Mvc project now targets and supports ASP.NET MVC 2, and provides more features and functionality that was there in 3.8.3.

This is a stable beta, given the small number of changes (other than the MVC support). So if you are affected by any of the issues listed in the change log I strongly recommend moving from 3.8.3 to 3.8.4 beta to test and utilize the changes.

Friday, June 25, 2010 11:19:03 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Tuesday, June 8, 2010

Over the past few months I’ve been researching, writing and speaking about MVVM quite a lot. One of the teaching tools I’ve developed has turned out to be useful for both teaching and actually building applications. This is the Bxf (Basic XAML Framework) code I’ve developed.

I must confess, I have little interest in becoming a UI framework author. But I also recognize that you can’t do any UI pattern like MVVM (or MVC) without some minimal framework support – there’s just some plumbing code you must have for the pattern to be actually useful.

Bxf is the minimum set of functionality I’ve been able to identify to support MVVM, with a couple other key goals:

  1. Support MVVM so a developer only creates a View, ViewModel and Model
  2. Same functionality/code in Silverlight and WPF
  3. Zero code-behind the XAML – any UI code goes in the viewmodel, and binding/commanding/trigger actions are used to allow the view to interact with the viewmodel
  4. Enable the use of the Visual Studio 2010 XAML designer (“Cider”), most notably the drag-and-drop data binding support it provides
  5. Enable the use of Expression Blend

I’ve included Bxf in some samples from the Visual Studio 2010 launch and for CSLA 4. But I’ve decided that’s too random, so I created http://bxf.codeplex.com to house the code.

My hope is that other people who find Bxf useful might choose to join the project as contributors and extend it to be more broadly useful. However, I also hope that the framework remains extremely simple and minimalistic (since there are already several quite robust and complex frameworks out there for people who need more than a simple solution can offer).

Bxf | Silverlight | WPF
Tuesday, June 8, 2010 12:23:23 PM (Central Standard Time, UTC-06:00)  #    Disclaimer

Know CSLA .NET? Looking for a job with a cool company?

Magenic is hiring CSLA developers for consulting work, so if you want to work for a great company, with some really fun and smart people, often using CSLA, you should contact one of our recruiters!

p.s. Magenic is also open to working with independent contractors through a subcontract agreement, so let us know if you are interested in that as well, thanks!

Tuesday, June 8, 2010 11:49:14 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Wednesday, June 2, 2010

I am working on a video series discussing the use of the MVVM design pattern, plus a “zero code-behind” philosophy with CSLA .NET version 4.

I’ve decided to put the intro video out there for free. It is a good video, covering the basics of the pattern, my approach to the pattern and how a CSLA-based Model works best in the pattern.

http://www.lhotka.net/files/MvvmIntro.wmv

The rest of the series will be demo-based, covering the specifics of implementation. I’ll add another blog post when that’s available for purchase, but I thought I’d get this intro online now so people can make use of it.

Wednesday, June 2, 2010 12:36:58 PM (Central Standard Time, UTC-06:00)  #    Disclaimer