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.

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 am more familiar with the idea of Microsoft’s .NET platform, Ruby on Rails, Django, CakePHP, symfony, Prototype, etc. as real development frameworks. These are just a few of the myriad frameworks coming out these days. One might say that programming is now going to two camps–the true coders who come up with the frameworks and those that only use these frameworks for their apps. Nothing wrong with the latter, but can you really be considered a programmer when you are simply stringing together someone else’s code? But I digress….

Anyway, the interesting thing is that the only difference between a highly configurable web application like Drupal or WordPress and a framework like Ruby on Rails is that with the former, you are given an example application out of the box, and you’re encouraged to stick somewhat close to the original design and intent. With Rails or symfony, you are given a blank piece of paper and some really great tools. However, those tools keep you somewhat closed in to all the possibilities. If you want to go outside of the intent of the framework, you still have to extend it.

This is really no different than the modular and themed nature of the afore-mentioned open source web apps. I think it really becomes a matter of preference. If you are a tinkerer, you’ll probably do better to stick with WordPress or Drupal, figure out how to make it conform to your designs, and you’re done. I like this, but I’m much more likely to want to start with the blank sheet of paper. I just like the agony and the ecstasy of building things from scratch.

Just ask my friend Randy Hoyt. I have been on WordPress for years now as a “temporary solution” as I build my great authoring platform (still WordPress). He took WordPress, loved it, and made it look like nothing I’d ever seen. In the end, they’re all frameworks.