Sunday, January 25, 2009

C# MVP For You and Me - Part 1 - Intro

This post is the first in a series about technology choices and patterns I used to build a C# rich client GUI. It's written from the perspective of an experienced Java developer who, three weeks ago, had never worked in C# or .NET. Learning the language was easy but learning the UI toolkits and best practices was hard, and thus worth writing about and sharing. I especially hope that the patterns piece will be helpful to the reader.

In this post I talk about the UI toolkits and the need for design patterns. In the next post I'll talk about actual patterns, and how I came to understand a way of using a lightweight model-view-presenter (MVP) pattern implementation to get the job done.
  • C# Rich Client Libraries - there are two: WinForms (old) and Windows Presentation Foundation (WPF - New). I chose WinForms because WPF is still only a few years old, and the WPF datagrid widget is only three months old. Also, people have been complaining about font blurriness in WPF - here is a post showing MSDN comments spanning two years on the issue, which is still unresolved. WPF is definitely prettier and is faster if you have the right graphics card. In terms of architecture and implementation, it is completely in tune with modern UI trends, enforcing separation of data from presentation and featuring a declarative UI definition language. WPF is the future, but WinForms' reliable nearly 10-year old datagrid was the route to take for this project. I refuse to be the guy who tells the traders they're losing millions of dollars because of "a bug in the rendering toolkit." Still I'm encouraged by WPF and look forward to revisiting it next year. Here is one of the more thoughtful articles I've read on WinForms vs. WPF.

  • The Need For Patterns - C# 3.0, the MS Visual Studio 2008 toolset, and the Microsoft databinding API make it shockingly simple to build databound visual apps. In his comprehensive and thoughtful book, Data Binding in Windows Forms 2.0, author Brian Noyes starts chapter 1 with a demo of that very capability. In minutes, he walks you through steps that generate a fully-functional custom GUI for browsing a database. This is light-years ahead of Java Swing and the dev tools that go with it. Writes Noyes at the end of the demo: "If you aren't saying 'Wow!', then you are either really hard to impress or you haven't spent much time trying to write applications like this." I was saying "wow!"

    I was also saying "uh oh," because what the tool clearly built was a classic two-tiered app with the GUI wired directly into the database, with data access code sitting directly inside the GUI widgets. It was essentially VB/Access, only in C#. Architecture 101 tells us this is bad, for all the standard reasons: it's unscalable (hitting the database directly, not through connection-pooling middleware), unmaintainable (every user's UI code breaks if the database schema should change; spaghetti data access code is repetititously scattered throughout the presentation layer; architecture is essentially non-existent), and untestable (short of visually testing everything by hand.)

    At the end of the chapter, Noyes himself says "uh oh":

    The thing you need to realize is that Visual Studio capabilities have the potential to encourage you to employ bad design practices. As you saw in the walkthrough example earlier in this chapter, there is a rich data-binding experience in Visual Studio within a Windows Forms application if you pull the database information directly into your Windows Forms project, create a typed data set and its associated data adapters in the project, and then set up the data binding based on the data sources that result. However, if you follow that pattern, you are putting data access code directly in your Windows Forms project, which is exactly what you shouldn't do . . . So even though you will see a lot of demos that do this—and I even do it in some places in the book to simplify the samples . . . you shouldn't plan on doing this in production applications.
    His book has some good examples of patterns, but focuses more on databinding itself, since that's the title of the book.
There was clearly more power here than in any tools I'd used before. There was also a great potential for misuse. I wanted to bring my Java experience of UI design patterns to bear on the project, but I was uncertain and unsure because the C# language, API, and overall developer lore were still so new to me. I did a bunch of research using Noyes as a starting point. It worked out really well and I'll share the summary in my next post.

1 comment:

  1. This comment has been removed by a blog administrator.

    ReplyDelete