Monday, January 4, 2010

MultiuseModel-View (MMV) Object modeling pattern with WPF and WCF: Genesis

In my previous article I gave a basic introduction to the Multiuse-Model View pattern. In this short article I will explain in detail the concepts behind a MMV library.

The Multiuse-Object Theory

A well organized framework is highly dependent on inheritance and encapsulation to avoid messy code and unnecessary overhead. Let's take the WPF framework itself for instance: when you are dealing with controls... say... a Button, you are dealing with a class that inherits from DispatcherObject, DependencyObject, Visual, UIElement, FrameworkElement, Control, ContentControl and ButtonBase. Each of these parent classes provide a different piece of functionality to their children such that by the time we get to deal with the Button class, we only have to worry about a few methods and properties to make the button show up on the screen and display text (or other stuff) inside and handle user events.
Likewise, with our Multiuse-Model approach, we want a set of classes that provide basic functionality to our business objects in order to encapsulate operations related to databases, client-server communications and even property notification changes.
In my previous article I wrote about lumping all this functionality in one single class, the MultiuseObject class, however, for large scale applications this would be cumbersome since the amount of functionality in a realistic framework is excessive for a single class. For this reason it is better to slice and dice each set of functionality into their own classes. At a minimum you should have the following classes as parents of your business objects:

  • ObservableObject: provides implementation of INotifyPropertyChanged for properties and ICommands for methods.
  • DatabaseObject: provides functionality to retrieve and store information on a database (there are many good data-layer libraries already, this object would wrap their functionality).
  • CommunicationObject: provides client-server communications.
  • MultiuseObject: wraps all functionality in a nice and neat package.

These classes are listed in order of inheritance, since, it is likely that sometimes you might not need to deal with the entire functionality. For example, sometimes you will have UI-only objects that would inherit straight from ObservableObject opposed to MultiuseObject.

In my next article, I'll demonstrate how to create an enterprise level ObservableObject class.


  1. Howdy,

    Thanks for the clear and concise article.

    I find MMV interesting and intend to use it on the project I am beginning (related to Cat Shows).

    My only block at this point is in loading MMVSamplePrivateServer and MMVSample.PublicServer in the SharpDevelop IDE that I use.

    The other projects load and build fine. But it seems #Develop doesn't recognize those two.

    Are they simple DLL Assembly projects? (in which case I can re-create them), or actual "service" projects? or some other kind of project?



  2. Hey Jesse,

    The PublicServer and PrivateServer are "ASP.NET development server" projects which means that when you debug them with Visual Studio, they'll run within a new instance of visual studio's ASP.NET server.

    These projects are nothing more than an library project with a definition added to them. If you open up the .csproj files and remove the following sections, you should be able to open them and compile them with #Develop (although you'll have to manually deploy the output to IIS).




  3. <ProjectExtensions>
    <FlavorProperties GUID="{349c5851-65df-11da-9384-00065b846f21}">