Smart Client

CAB is dead! Long live CAB!

Brad Wilson — Wed, 06 Jun 2007 09:50:00 GMT

When I left p&p, one of the teams I was considering was the Acropolis team. It would've been an opportunity to go do CAB as a fully supported development environment enabled thing, rather than just a raw framework from a few people. I'm glad they've announced it now, so people can see the direction that Microsoft is headed in. Glenn Block from p&p has a post about the future of the smart client p&p deliverables in light of this announcement, too.

I wonder if there's someone on the net who thinks he can re-implement Acropolis in 15 minutes? ;)

Frameworks vs. Libraries

Brad Wilson — Wed, 30 May 2007 00:03:00 GMT

There's a bit of heat about CAB and p&p going on right now, and I haven't decided if I want to jump in yet.

I do, though, want to address a point by Jeremy Miller:

Tools that amount to "just something that you use" like NHibernate, or log4net (but I'm not letting them off the hook for the versioning and breaking API hell a couple years ago) are not intrusive. You just use them when you need the service that they provide. Tools and frameworks that are intrusive into your code, or even worse, require you to wrap your application around their opinionated structure are a different story altogether.

Peter describes the former (log4net, etc.) and libraries and the latter (CAB) as frameworks.

I can take an existing application and add logging with log4net, because it makes very few demands on me. I basically make calls to it. Using CAB in an application is a commitment, because it describes the way you should build your application. It's a framework, and in most cases, it's calling me rather than me calling it. Peter's "easy test" to tell a framework from a library is the Hollywood principal: if the thing is always saying "Don't call me, I'll call you", then it's a framework.

There's no question that the investment required to use a framework is significantly larger than the investment required to use a library.

And, my 2c, is if there is any single failing of Enterprise Library, it is where it tries to behave like a framework where it should instead be acting like a library. Baking the configuration system into EntLib and making it hard to use without it is the most obvious example of this behavior. Scott and I (and others) have had many discussions about this in the past (read his latest blog post for some in-depth thinking about it).

What's Right About Lambdas and LINQ

Brad Wilson — Sat, 21 Apr 2007 07:55:00 GMT

Two features coming in C# 3.0 are pretty exciting, even though I may have initially (incorrectly) dismissed them a gimmicky.

Lambda Expressions are nice because they are syntactically simpler anonymous delegates, and hands down, anonymous delegates were the best feature of C# 2.0. Generics might've saved us some casts, but anonymous delegates saved us from making whole methods or types, and because they're closures, they eliminate the need for nasty things like passing opaque objects through callbacks. Lambda Expressions make anonymous delegates compact and readable. This was a no-brainer for me.

I was less sure about LINQ. With LINQ Expressions, you can write vaguely SQLish code:

IEnumerable<Person> results = from p in people
                              where p.LastName.StartsWith("G")
                              orderby p.FirstName
                              select p;

or the more explicit:

IEnumerable<Person> results = people.Where(p=>p.LastName.StartsWith("G"))
                                    .OrderBy(p=>p.FirstName);

There are obvious reasons to like this: no chance for SQL injection bugs, don't need to switch your brain from C# mode to SQL mode and back, hiding the simpler differences between database engines, etc.

There's a bigger bang for the buck hiding here, though: it's very likely to make database refactoring dramatically simpler. I like being able to think about all of my database operations in terms of my native development language. Rails does this today with Migrations, and C# 3.0 could benefit from a similar system.

It will really hit the 85% problem well, and then we can build intelligent database refactoring systems that understand how to build migrations as well as modify the query code, without ever having to touch SQL in the process. We can also use static analysis tools to find simple performance issues (missing indices on things that are used in where clauses, for example). The wealth of value that opens up here is almost staggering.

Technorati tags: C# 3.0, Lambda Expression, LINQ, refactoring, agile, database, SQL

Whose Thread Is This, Anyway?

Brad Wilson — Wed, 22 Nov 2006 09:38:00 GMT

Being involved a lot with smart client applications and platforms, I get asked a lot about dealing with background threads, especially as it pertains to things like Model-View-Presenter. One very common question is: "When work is being done on a background thread, whose responsibility is it to get back to the UI thread when it's time to do UI work?"

Although we gave help for this in CAB's event broker, this always felt a little odd to me (not the least of which because it was only available to event handlers). I actually believe that this behavior belongs in the view. There is a temptating to want to put this logic in the presenter, because MVP encourages you to keep your views to be as dumb as possible.

While I appreciate that sentinment, if you think about isolating details of your architecture, it makes sense to put this into the view. Should your presenter to be aware of the type of view that it's being used in, and the details of which thread is appropriate to be called back on? Aside from the "typical" WinForms rules, how does the presenter know which thread is the right one?

In the end, only the view has the appropriate information to make that judgment call about which thread is appropriate and when. When using WinForms, this means using InvokeRequired/BeginInvoke/EndInvoke. Keeping this in the view means that the presenters remain agnostic to the view technology, and it makes it simpler to migrate to some new presentation technology without changing the presenters.

The code to do the work is relatively simple. Here is a fully formed example.

using System;
using System.Threading;
using System.Windows.Forms;

namespace WindowsApplication1
{
    static class Program {
        [STAThread] static void Main() {
            Application.Run(new Form1());
        }
    }

    public partial class Form1 : Form {
        public Form1() {
            InitializeComponent();
        }

        protected override void OnLoad(EventArgs e) {
            base.OnLoad(e);
            new Thread(delegate() {
                Thread.Sleep(1000);
                Console.WriteLine("The result is: {0}", MyMethod(10, 4.2));
            }).Start();
        }

        delegate double MyMethodDelegate(int x, double y);

        public double MyMethod(int x, double y) {
            if (InvokeRequired)
                return (double)EndInvoke(BeginInvoke(new MyMethodDelegate(MyMethod), x, y));

            return y * x;
        }
    }
}

If you've used the Smart Client Software Factory, you can see that we use this pattern in our sample applications. The debates in the room landed us on this pattern, and I think we were all pretty happy with it in the end.

In an ideal world, ObjectBuilder would offer AOP facilities; then, you could write a strategy that watched the creation of any class that derives from Control, and wrap public methods and properties with this boilerplate code, either automatically or on the basis of some metadata like an attribute.

Now playing: Kyle Quit the Band - Tenacious D

Smart Client Software Factory Ships

Brad Wilson — Sat, 01 Jul 2006 11:59:00 GMT

The last project I worked on at p&p was the Smart Client Software Factory (previously known as Smart Client Baseline Architecture Toolkit, or SC-BAT).

I just got the notice that they shipped to MSDN yesterday. Congratulations to the team!

My Parting Gift to the CAB Community

Brad Wilson — Fri, 12 May 2006 14:23:00 GMT

Today is my last day with patterns & practices.

I joined p&p 14 months ago as my first stop in Microsoft. In my time here, I got to work with some great people. I can't name them all, because it wouldn't be fair to forget someone, but it almost goes without saying that people like Peter Provost, Scott Densmore, Brian Button, Ed Jezierski, and Ward Cunningham had tremendous impact on my time here. Three of them have already moved on, and now it's my turn. Another post on another day will talk about what I’m doing next.

Peter got tired of my Short-Timer’s Syndrome, so he sent me to pinch-hit on the Smart Client Software Factory project (a team I’d left about a month ago). At the iteration planning meeting last Friday, we decided to tackle one of the issues people have with CAB: the module loader. Specifically, we wanted to address two things with this code update: 1. Fix a bug regarding the order of WorkItemExtension registration, and 2. Move the dependency information out into the XML file and make it richer, to enable scenarios like grouping modules together into sections for layout, services, and applications.

The code for the new module loader will be in the SCSF community drop on Monday. I've written an article which describes the new module loader and supporting classes in detail.

Enjoy!

Now playing: Joe Satriani - Redshift Riders

Speaking at p&p Summit Boston

Brad Wilson — Sat, 11 Mar 2006 00:01:00 GMT

I found out today that I'll be speaking at the patterns & practices summit in Boston in two weeks. I'm still negotiating what my talks will be, but undoubtedly there will be some coverage of Smart Client stuff (CAB and/or SC-BAT) as well as agile topics.

Update: I got my list of scheduled topics.

On Wednesday morning I'll be talking about Smart Client Baseline Architecture Toolkit (SC-BAT), which will offer an overview of what the project is and how architects can use our toolkit to create their own baseline architectures.

On Thursday morning I'll be talking about ObjectBuilder, our framework for building dependency injection systems. This is the first time we'll be talking about ObjectBuilder publicly, and probably the only time this talk will be given at a Summit. It will be quite different from the DI talk that Peter and I did at Seattle Code Camp; instead of talking about dependency injection in the abstract and showing an OB wrapper, I'll be talking about what OB is, where we've used it in p&p, and how you can use it to create your own customized Dependency Injection framework.

CAB Hands on Labs available (C#)

Brad Wilson — Thu, 29 Dec 2005 12:33:00 GMT

We shipped the C# version of the Hands on Labs last night to GotDotNet. You can download them here. Note that these versions of the labs require the December 2005 C# version of CAB.

p&p Live Webcast: Lessons Learned from the Warroom

Brad Wilson — Sun, 11 Dec 2005 14:48:00 GMT

It seems like I'm last to the party here. :)

On December 1, we (Peter, Brian, Darrell and myself) did a webcast talking about our lessons learned from the patterns & practices warroom, especially as it relates to agile development. Get some insight into the way we work, and the successes and challenges we've had doing agile development inside of Microsoft.

Enjoy!

CAB Released to MSDN, Visualization Sample Released to GotDotNet

Brad Wilson — Wed, 07 Dec 2005 11:54:00 GMT

Yesterday the MSDN page for CAB went live with the final bits for both C# and Visual Basic .NET.

We did not intend to change the C# code from the November release. However, we coded ourselves into a bit of a corner, and the VB port caused us to make some small but necessary API changes (stuff that hardly anybody would notice). We thought that API compatibility was of the utmost importance between C# and VB, so we decided to re-release C#.

Being typical developers, we seized the re-release opportunity to fix a few bugs from the community in both the C# and VB release. If you've previously downloaded the November release, it's worth downloading the December one and using that instead. We released a list of things we changed and fixed between November and December.

We also released our first Sample Visualizations package to the GotDotNet community. Right now it only includes a single simple visualization which can show the WorkItem hierarchy of a running CAB application. Just as important, it includes some preliminary documentation on how the visualizer system works in CAB and what is required to write your own visualizations. Hopefully we'll be able to release new sample visualizations on a regular basis that provide additional debugging assistance for CAB developers and administrators.

Next up: sample code on using ObjectBuilder as a true dependency injection container.