The first video in the series is available for free from the download page, so you can get a better idea about the approach I’m taking in using MVVM with CSLA 4 and Silverlight or WPF.

This is a six part series (nearly 3.5 hours of content) covering the Model-View-ViewModel (MVVM) design pattern and how to efficiently apply it when your model is constructed using CSLA 4, and your UI is built using Silverlight or WPF.

That means you have a rich business domain model that fully encapsulates your business logic (validation, authorization, calculations, etc), and those objects (thanks to CSLA) fully support all the data binding semantics for Silverlight and WPF. And it means you have access to useful helper components and controls from the Csla.Xaml namespace, including viewmodel base classes, validation information display and UI event triggering to help wire up UI events to viewmodel verbs/methods.

The series also makes use of the Bxf framework, which is an extremely lightweight MVVM UI framework designed to illustrate the basic concepts of an MVVM framework. Like MVC, it is really impossible to make effective use of the MVVM design pattern without some level of framework support. Something has to manage the creation and display of views, and the process of wiring up a viewmodel to a view, just like something has to route commands to a controller and render views in MVC. Bxf is the smallest possible set of framework behaviors I’ve been able to identify that makes MVVM practical to implement.

As a bonus, the sixth video in the series discusses how to apply the concepts from the video series in CSLA .NET 3.8.4 with Visual Studio 2008. Even if you can’t move to CSLA 4, .NET 4 and Visual Studio 2010 yet, the vast majority of the content in this video series is still valuable!

If you are using CSLA .NET to build Silverlight or WPF applications, or if you want to explore some practical ways to think about and implement the MVVM design pattern, this video series is a must have!

This is kind of a running commentary, or personal log (stardate July 2010), recording the various things I had to do to get the CSLA 4 Silverlight codebase to build in the WP7 (Windows Phone 7) beta SDK.

This has nothing to do with getting anything actually running – this is just the stuff I had to change to get the code to compile.

To create the Csla.Wp project, I just linked in files from Csla and Csla.Silverlight. There are almost no actual files in Csla.Wp – it is almost completely reusing the same code used to implement Csla.Silverlight. That’s really cool, as it means my maintenance burden is (theoretically) quite low.

(though this exercise did highlight the need for me to go through the Csla and Csla.Silverlight projects to remove all code files from the Csla.Silverlight project too – ideally there’d be exactly one of any given file, with a few #if statements to deal with platform differences – but that’s a task for another day)

Most of my issues building on WP7 turned out to be caused by the fact that CSLA 4 targets Silverlight 4, and WP7 is based on SL3.

Missing: DataAnnotations

Missing: Reflection.Emit

Missing: Lambda expressions

Missing: string.IsNullOrWhiteSpace

Missing: Browsable attribute

Most of the DataAnnotations code I just had to block out with #if statements, though I did create my own DisplayAttribute class because I don’t want to lose that particular feature (the friendly name part). So business classes using that particular attribute should work fine, but the other DataAnnotations attributes won’t compile in WP7.

I also created my own BrowsableAttribute class, even though it doesn’t do anything. This saved me from littering tons and tons of code with #if statements, and I can’t see where it hurts anything to have this dummy attribute in my code. The attribute normally just affects the behavior of Visual Studio, which wouldn’t be affected either way.

The IsNullOrWhiteSpace method I just replaced with the (not as good) IsNullOrEmpty using #if statements. A little cluttered, but a workable answer.

What I’m working on now is the final part: dealing with the lack of lambda expressions and dynamic methods. Basically I need to revert the CSLA code back to using raw reflection in those cases, since none of the modern reflection alternatives appear to exist in WP7. That shouldn’t be too hard, as I can get most of that older code from earlier versions of CSLA and just put it into the existing codebase using #if statements (so I don’t affect the .NET or SL implementations).

Given the size and complexity of CSLA 4, I’m really quite pleased with the relative easy by which I’ve been able to get the code to (almost) build in WP7.

This is a major release of the CSLA .NET framework, not only because of the support for the Visual Studio 2010 wave of technologies from Microsoft, but also because of significant changes to CSLA itself based on feedback and input from the vibrant CSLA community.

As always, CSLA .NET couldn’t exist as it does without the strong support I receive from Magenic. Thank you!

CSLA 4 is the result of a lot of effort on the part of a global development team:

Jonny Bekkum is a C# software architect and developer at InMeta ASA in Norway. He has been developing large-scale enterprise applications on .NET and other platforms for more than 20 years, working in financial, retail, public and betting industries. Jonny has been using CSLA .NET since 2005.

Sergey Barskiy is a principal consultant with Magenic. He is a Microsoft MVP. He has been in IT industry for 15 years. He has been using CSLA for 3+ years.

Justin Chase is from Minnesota and currently works for Microsoft on the Expression team. He has been a CSLA contributor for more than 3 years and has a special interest in DSLs and code generation.

Blake Niemyjski is a Software Development Engineer with CodeSmith Tools and a student at UW-Platteville. He has been a contributor to various open source projects over the past three years. In his spare time he enjoys flying, learning about new technologies and contributing back to the community.

Ricky Supit has been developing software professionally for almost 20 years. He currently is focusing on web development technology including ASP.NET WebForm/MVC, Ajax, jQuery, and Silverlight. Ricky has been using Rocky Lhotka’s CSLA framework since Visual Basic 6.0. Ricky is currently working as software development manager for a fortune 500 health insurance company. He has a master degree in Computer Engineering.

Peran Borkett lives with his family in South East England. He has worked as a software consultant in the City of London financial district for over 12 years. He has been using CSLA for several years and has recently started contributing to the framework.

Rockford Lhotka is the creator of the popular CSLA .NET development framework, and is the author of numerous books, including Expert 2008 Business Objects. He is a Microsoft Regional Director and MVP, and a regular presenter at major conferences around the world. Rockford is the Principal Technology Evangelist for Magenic.

CSLA 4 includes significant new features. See the change log for a complete history of the changes from 3.8 to 4. Here are some important highlights:

Requires Visual Studio 2010, .NET and (optionally) Silverlight 4

New business and authorization rules system (details here, here and here)

Base list/collection types are now ObservableCollection for WPF; (BindingList implementations still exist for Windows Forms and some third party WPF controls)

Support for MVVM in Silverlight and WPF

Support for new Silverlight 4 data binding and validation features

Support for ASP.NET MVC 2

Allow an object to be bound to multiple bindingsource controls in Windows Forms

Silverlight data portal is now as extensible as the .NET data portal

Rework LINQ to CSLA to be easier to use

.NET unit tests now run in mstest (though you may still be able to run them in nunit with some work)

New solution and project structure to isolate UI technology support from the core framework

Consolidated release for .NET and Silverlight

Since this is a major version change (from 3 to 4), there are numerous breaking changes, which are highlighted in the change log.

In terms of future activities:

I am actively working on ebook and video content covering CSLA 4. Right now you can get special pre-release pricing on the CSLA 4 MVVM video series at http://store.lhotka.net. Watch for more ebook and video content on the store over the next few months.

I am also actively working on CSLA 4 for Windows Phone 7, and I’ll have more information about this over the next few months.

I hope you enjoy CSLA 4 and find it useful in your development efforts. I know the CSLA 4 development team has put a lot of work into this release, and we’re all excited to see how people make use of it to create cool applications.

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.

Use a pattern because you have the problem it solves

Only use a pattern if the good consequences outweigh the bad (and remember that every pattern has negative consequences)

Use patterns and implementations only if the entire team understands them

Use the simplest pattern that solves your problem

Don’t be afraid to combine several simple patterns to solve a complex problem

Be aware of (and consciously accept) the consequences of any low level patterns that come with most high level pattern implementations

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.

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:

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:

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:

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.