Here at work we have a fortnightly meeting of all six developers (when we can all make it) that we call the "developer jam session." It's two hours every two weeks where we can get together and talk about what we've been up to, and play around with various side projects.

At our last meeting we decided to kick off a new practice project. Rather than doing things the way we always do 'em - using typed DataSets and .NET 2.0 WinForms - we decided to catch up with the rest of the development world and try using an object model and WPF.

So I'm going to use this post (and perhaps a series of posts) to document what we're doing. I'm not saying that this is the right way to do it - far from it. In fact, this is more a request for comments from those of you who have developed real applications this way for years. Let me know what we're doing right and wrong, so we don't make too many false starts.

This particular application is starting small. Really small. It's a single SQL Server table of "trainees" who have an ID (uniqueidentifier), a first name and last name (varchar(50)) and a bit column representing whether they're "active". The program will need to be able to retrieve a list of all trainees and allow the user to add new ones and edit (including "deactivating") existing ones. Once we get it to that point, we're going to start adding new requirements and features.

The object model, then, as you'd imagine, is a single class called Trainee. It lives in its own little assembly and namespace (Qaf.TrainAlloc.ObjectModel), and looks like this:

 public class Trainee : INotifyPropertyChanged  { public Trainee() { ID = Guid.NewGuid(); IsActive = true; } private Guid _id; private string _firstName; private string _lastName; private bool _isActive; public Guid ID { get { return _id; } set  { _id = value; OnPropertyChanged("ID"); } } public string FirstName { get { return _firstName; } set  { _firstName = value; OnPropertyChanged("FirstName"); } } public string LastName { get { return _lastName; } set  { _lastName = value; OnPropertyChanged("LastName"); } } public bool IsActive { get { return _isActive; } set  { _isActive = value; OnPropertyChanged("IsActive"); } } protected void OnPropertyChanged(string propertyName) { if (PropertyChanged != null) { PropertyChanged(this, new PropertyChangedEventArgs(propertyName)); } }  #region INotifyPropertyChanged Members public event PropertyChangedEventHandler PropertyChanged;  #endregion  }

Pretty straight forward. We've implemented INotifyPropertyChanged up front because we know that we'll be binding to this class. We're doing it the .NET 2.0 way for now, because I think I was the only member of our group who had even heard of DependencyProperty, and it was a bit of a leap to use that straight away. We might change over to dependency properties at a later date.

The next step is to be able to retrieve a list of all trainees from the database, which will be the next post.