If you want to make sure changes to your source object are reflected in your view, your source object will need to implement INotifyPropertyChanged (see example). Yet just implementing this property will not necessarily update your bindings. If your source object includes collections, and you bind to properties in those collections, you can update the source property but will not get updates from the source property, even if it is of a type that implements INotifyPropertyChanged.

The above scenario is common with Linq to Sql when the entities are generated for you. Even tables with one-to-one mappings will be generated with lists–as SQL doesn’t have a way of representing one-to-one relationships–so be sure to edit your dbml accordingly in order to take advantage of binding to your source object’s properties. (You might also consider removing some relationships to remove issues with DataContext collisions when trying to set properties of one Linq entity to another.)

If you can’t fix the problem this way or want to display the collection and changes to the collection, you can always add an ObservableCollection to your PresentationModel or wrap the source object with another object that does use the ObservableCollection to display your collection.

Dan Crevier posted a series of excellent articles defining the pattern and giving examples of the implementation of MVVM in WPF. These were written several years ago, before development of the Composite WPF block, but they are simple to understand and can give added understanding to the objects included in Composite WPF. For example, his post on encapsulating commands is very similar to the DelegateCommand object provided with CompositeWPF, though the latter uses lambdas to define Execute and CanExecute methods, whereas the former uses a base class and inheritance to define the methods. Using Dan’s example, the equivalent DelegateCommand, contained within the DelegateCommand’s definition, would look something like this:

public DelegateCommand<object> MyCommand { get; private set; }

public Window1()
{
    InitializeComponent();
    MyCommand = new DelegateCommand<object>(
        p => {
                 string text = p as string;
                 // Do something with text
             },
        p => !string.IsNullOrEmpty(p as string));
}

Dan’s definitions of the Model, which he calls DataModel, View and ViewModel match very closely with Composite WPF’s PresentationModel pattern. In this case, the DataModel is a representative object that is fit for display within the View. Using the entities generated for Linq to SQL, you might add properties to the partial classes create the necessary properties to which to bind. These classes should also implement INotifyPropertyChanged so that other DataModels can respond to changes from another, related View and update their data accordingly.

The View should use bindings for everything. The beauty of WPF is truly in its DataBinding functionality. The observer pattern is built right into the Binding, so that whenever one view changes, other views are notified by their bindings to their DataModels. Even the actions to be performed on a user interaction with the UI can be removed to the ViewModel, DataModel, or in the case of Composite WPF, a controller, Shell, or App level, as appropriate. This leaves the View looking very passive, indeed, which greatly helps when unit testing.

The ViewModel is the actual PresentationModel. It hosts the DataModel, as well as the View’s commands. ViewModel should be the object used to bind to the View’s DataContext and should implement INotifyPropertyChanged if any of the properties could change. The QuickStarts and RIStockTrader examples provide excellent samples of the PresentationModel, though be warned that the examples often use different patterns, if for no other reason than to show other pattern implementations.

That covers the MVVM pattern. However, there’s one more aspect that needs to be covered: composite regions. Composite WPF provides regions for managing the display of different modules in the Shell, but what if you need to display multiple modules or views within a “summary” view that is already on the Shell? In this case, you can use a Controller to manage the child use cases. The UIComposition QuickStart shows a terrific example of creating a controller in a ViewModel for the purposes of managing child use cases. This removes the dependencies and depth of a View that includes a tab control containing a large number of child use cases. (The UIComposition QuickStart uses a Supervising Controller pattern instead of the PresentationModel/MVVM pattern, so you’ll have to adjust it accordingly, but it works beautifully.)

The MVVM pattern is a great solution for WPF applications by allowing WPF’s DataBinding and Commanding to remove much of the logic formerly found in the View layer out to a unit testable ViewModel. The architecture stays clean and also fairly shallow in that an additional Presenter class is unnecessary (as opposed to the Supervising Controller pattern.)

Additional Resources:

• John Grossman – Tales from the Smart Client
• Pete Weissbrod – Model-View-ViewModel Pattern for WPF: Yet Another Approach

I read your comment before reading the article, and I originally agreed with your comment. Then I read the article, and I can’t help agreeing with almost every point. Almost. At the same time, I still agree with your comment. I know that probably sounds ridiculous, but it’s true. Everything you said is spot on target. Maybe explaining my thoughts, having read both, would help.

After reading the article, I can’t help thinking that RDF really doesn’t belong within (X)HTML. This is a pretty big deal for me, but I can’t get away from it. From a truly semantic pov, (X)HTML describes a document. I realize that it has been exploded to do all sorts of amazing things, but it is, at it’s roots, a document format. Why force even more into an almost back-broken format? (X)HTML’s own tags can provide a load of semantic information about the document, and that’s really all it should provide.

Microformats are a great way of recognizing that and staying fairly consistent to that nature, but they really aren’t a very good solution. Creating RDF using n3 is much easier than XML, though both are fine, and are much easier to create independent of (X)HTML. Building a tool to create RDF data to store at a specific URI would allow so much more data to be placed out on the SemWeb much faster. Then, using the rel and rev attributes already in (X)HTML, you could extract triples to relate web pages (HTML) to web resources (RDF, etc.) and complete the graph without trying to force in so much more information than necessary into (X)HTML.

Maybe I’m a bit naive, but that seems like a really workable solution. And if you must find a way to represent all RDF as a (X)HTML, XSLT and XQuery are great tools for doing just that, keeping in mind you are now creating a document to display data for the resource. Standard templates/queries should be able to go a long way–sort of a reverse GRDDL approach.

Or am I just missing something huge and obvious? (I tend to do that sometimes.)

If you read my previous post on the Future of Web Applications, you may think I already thought this. Well, I wish I had, but at the time I hadn’t quite reached this point. After all, I thought embedding resources within (X)HTML would make everything more maintainable. However, maintaining data on a person, event, etc. is much more easily done in one place and then linked by others. Why embed something that may already exist elsewhere? And why make your web page, which may only haphazardly relate to the embedded content, the responsible source for maintaining that embedded item?

Rather, I’d love to see tools like WordPress and others provide tools for creating and managing this content locally or link to resources elsewhere, such as in your Google Calendar.

At this point, I’ve likely lost most of my readers who are here for one thing or another, except those interested in the topics in the title. And that proves the point, in the end. A personal blog is basically a lot of thoughts, asides, commentaries, etc. about a variety of topics with only one common theme: they are all about the blogger. While that may appeal to some people in some cases, generally the only people who read this are close friends and family, and that happens only so often. (On rare occasions, I’m pleasantly surprised by new visitors and contacts… Thanks!) Please also note that I’m not directing this at corporate blogs or blogs about one or a few closely related concepts.

Instead of such a personal blog (this one is a case-in-point), I’ve been thinking that the only reason to post publicly is to share what I’ve got. If no one reads it, however, then what good was posting it? And if I’m inconsistent or post on certain ideas only infrequently, how will anyone know or care when I’ve posted exactly what they’ve needed for days–here I’m alluding to the difficulty of finding good SharePoint development resources–when it’s my second post on the topic in six months? If I post on MSDN or SitePoint forums, however, not only will a lot of people likely see it, but I may even be able to discuss other ways of doing what I’ve suggested or even learn ways to improve.

I’ve come full circle once again. Why have a blog? I really can’t think of a good reason. However, I can think of a really great reason for continuing to use WordPress and maintain a personal site: a personal site can act as a hub for all of my online activities and accounts, and at some point, potentially bring all the posts I contribute elsewhere back here for a central picture of what I do online. (Of course, sites like Twine and Facebook already do that on some level, but there’s nothing like having your own, decrufted domain name!)

The only problem, at this point, is that WordPress does not tie into the Semantic Web at the moment. This is changing with goodies like BuddyPress, SparqlPress, wp-openid, etc. I’m most excited about SparqlPress, which will really tie WordPress into the Semantic Web by pulling user information from FOAF profiles using SPARQL queries (see the example).

However, even with these great steps forward, I’m still missing something. WordPress is a personal publishing platform, but it doesn’t publish semantic data in the form that can be used to link to data on other sites. What I want to do is create a plugin to allow WordPress to embed RDF metadata into every post, page and link on my site using standard rules. I’ve started evaluating which content type works best for various types of data (see my list of “Online Accounts” links in the sidebar). At some point I’ll figure out
how to pull my content elsewhere back into my personal feed (i.e. “blog”), but that’ll remain for a later task.

Anyway, I’ll probably keep posting some stuff here, but it’ll really be thoughts that don’t seem to be better posted elsewhere. Over time, this site will start really looking like a hub about me and less like a blog… but I’ve said similar things before…

I recently listened to Douglas Crockford‘s State of Ajax presentation and thought he made excellent points:

• JavaScript is a terrific language, it’s just misunderstood
• CSS is probably the weakest link because it was designed to layout print documents and has been made to fit flow documents (not sure I agree wholly with this, but it is a challenge)
• HTML has reached a point of confusion with the competing improvements from the W3C (XHTML2) and WHAT-WG (HTML5)

I certainly agree with point #1, that JavaScript is a terrific language. CSS… well, I’m okay with it. I fully realize I don’t understand it all that well (see the state of my current design), but I’m learning and I like it. I just don’t really understand why it’s not an XML language. (I do like that it’s not because it’s easier to write, but consistency is at least nice.)

With regards to HTML, I also fully agree, but almost for different reasons. HTML is a great platform for creating documents. However, all the extensions being added by WHAT-WG seem to miss the point and muddy the waters further. XHTML2 just realigns everything and adds some better links to other technologies like XForms, which is itself more a web form application language, not a document language. Thus, all the new versions make HTML more of a combination document/application platform. If that comes to pass, HTML will no longer really be good for anything in terms of semantics. It will have none and will instead lead to a new form of tag-soup: namespace soup.

Now, before anyone goes crazy on me, I don’t think all “web applications” break HTML. For instance, Google Maps is a great application, and I can appreciate making web-based documents (like maps) interactive, just as you might find a real map. I draw and mark up maps in real-life, so why not on the web? That makes perfect sense. A blog is also a great web app when I can edit it right there on the screen, just as though I were able to go back in my journal and either cross out or erase parts and re-write them. In some cases, web apps can be even better.

The part where all this breaks down, though, is admin screens and other forms. Sure, you can look at a web form as a document that needs to be submitted once complete, just like in real-life. But to then add all the javascript additions to auto-save frequently and refresh parts of the document? That’s no longer a document-style form; that is now an application, and I think that an application should be an application, not a hodge-podge of document and script.

I see Adobe Flash/Flex and Microsoft Silverlight (and maybe XForms, but I’ve recently lost a lot of interest there for many reasons to be explained in a bit) fitting in here well. If you’ve got an application you want to place online, you probably don’t need it to be spread across several pages. If you do, it’s not really an application but related pages. Also, if you need bookmark-ability, you can always add favorites to an application or allow the application to interpret parameters sent to the hosting web page’s address to load the application in a certain spot. Any way you swing it, your application has the following benefits:

1. It’s source is protected by default (if you desire that sort of thing)
2. The hosting HTML page can describe the application, which keeps the HTML full of solid, semantic meaning
3. The application is self-contained and therefore provides a rich, responsive user-interface for the user
4. The application can use other documents or resources on the web instead of both being the document and the application, again increasing the semantic meaning
5. A self-contained application doesn’t pollute the web with excess semantic markup (as would XForms) but allows the hosting HTML document to provide the semantic meaning for the application

I’m still thinking about all this, but with all the struggle over the future of HTML, JavaScript, and CSS, I don’t think we’ll see many innovations there (at least not cross-browser) any time soon, and I also don’t think they are really all that necessary. We’ve already got a superb foundation for building web applications. We should instead focus more on tying our applications to existing documents and resources on the web and increasing the semantic meaning of everything we do, without adding too much meaningless meaning. And we can do that today.

• Heroku for Ruby on Rails development
• Photoshop Express for image editing and sharing
• WordPress 2.5 for even more powerful blogging and now speedy image galleries
• Twine for linking your tagged based information together (M. David Peterson has had some very interesting blog posts about Twine recently.)
• Woopra for real-time site management that you have to see to believe; Google Analytics, eat your heart out!

See below for some interesting screenshots:

In addition, my friend Randy Hoyt and I each got to talk with Matt one-on-one, and we both came away excited about doing things that might help WordPress grow in the future. I am planning to start working on a plug-in for including RDFa in WordPress (similar to Drupal‘s announcement), and Randy is wanting to build a issue tracker. This all leads to WordPress being far more than just a blogging application; it really is a full stack application platform.

Kudos to the WordPress contributors and all who worked so hard to put this WordCamp together. Thanks also to the City of Frisco, TX, our hosts. Their council chamber, where the event was held, was very nice and comfortable. All in all, it was terrific, and well worth the drive from Houston to Dallas. If you are interested, several people were taking video, which may turn up somewhere. Just search for wordcampdallas2008, and you should get lucky. Also, Nathan Rice had a nice summary, as did John P. from OneMansBlog.com and Lorelle.

However, I was struck with an idea after reading the article. This type of functionality puts SQL Server on a level with eXist as an XML database server. By this I mean that lots of opportunities now open up to serving XML to a client application instead of using a lot of database resources. (For those unfamiliar with eXist, it has built in REST, SOAP, and WebDav services available out of the box; SQL Server has SOAP through the CREATE ENDPOINT statement.)

This led me to thinking again about the MVC design pattern and an ideal way in which to set up that pattern. I came to the conclusion that there are macro- and micro- versions of the pattern. Most of the time MVC is mentioned, it is in the context of keeping everything relatively within one language (e.g. ASP.NET MVC, Ruby on Rails or XForms). That would be an example of a micro-MVC pattern.

A macro-MVC pattern could be the separation of XML documents (models), Javascript (controller), and HTML + CSS + XSLT (views) as found in the freja framework. Most of those components are often seen in web development but not often considered when discussing MVC. Typically, only the language that produces the XML would be considered worthy of an MVC designation, if it also produced the other pieces.

Now to the point: one might use SQL Server to produce the XML models, C# classes to perform the duties of the controller (i.e. parsing URLs, XML, etc. and feeding the views), and either XForms or the HTML + CSS + XSLT trio for views. The best thing about this combination over using views with eXist is that SQL Server still stores its data in a relational database. A DBA could create the stored procedures necessary to create the XML documents and update the underlying tables, thereby keeping all of the business logic in one domain and truly separating models from controllers and views.

I’m going to make an attempt at using this methodology soon, probably with XForms as the view layer. I will be sure to post my experiences when I get further along.

I’ve so far tried Ryan Bates’s method to great effect, but it’s just not the route I want to go, and I can’t find an elegant way to start without Javascript. MCC looks really interesting, but now I’ve got to go to another layer of abstraction. Of course, with XForms, I will need a browser plugin, but I really like XForms, so I’m going to try it and see what I can make of it.

(Those familiar with XForms will likely point out that I’m now adding multiple levels of abstraction with XForms since it is, like Rails, also built on an MVC pattern. However, I’m choosing to look at this as constructing Rails web services and using another “app” to handle user interaction. Either way, they are probably right. I just want to have fun with it.)