I've written on the Observer Pattern before as I am using it in a smart client app. I'm starting to not have to think about it so much and am enjoying the power of it. Quick review, the Observer wires all events in various components and controls in a Windows Application, firing off events to which elements that have a reference to the Observer Subject can subscribe to. I adopted the pattern from the DevDays 2004 IssueVision Smart Client source. That app was understandably simplistic; real world apps get a bit more complicated and thus require more sophisticated logic to establish the Observer "Current View," or using filtering to display only those issues associated with a selected staff person, like in IV. This one-to-one relationship in IssueVision required nothing more than using DataView.RowFilter. The app I'm working on has many-to-many relationships to filter across several usercontrols of various datatypes, so I needed a different approach.
SQL Stored Procedure time. Below is an image of the Views table. For our purposes we'll say column #2 is a userID, column #3 represents a ViewType (by staff, companies, etc.) and column #4 are the jobs that user is associated with, retreived from several locations. Fortunately I blogged on converting tabular data to a delimited string in SQL before, so I had my how-to reference on Cursors. The integer in the next column represents the total number of projects to save coding and client processing time. The LastModified datetime field is used for data synchronization
I want to follow-up on this, but I thought I'd throw out this approach to establishing a more complex View Filtering approach with the Observer Pattern and serve as a demonstration of using SQL to do most of the heavy lifting to avoid writing excessive code on the client.
