For beginners to MCML, the most difficult thing to get used can be the idea of model-view separation.

Some developers may be very familiar with it – the basic concepts have been used for quite some time, particularly in the Document-View architecture found in a number of programming languages (including the Microsoft Foundation Classes) for many years. Others will have little to no experience with separation, and this post is for them.

Basic Concept

There are two parts of any model-view project. There’s the Model, which does all of the real ‘work’ of a program – gathering and processing data, communicating with other processes, performing logical operations etc. – and the View, which is the user-interface.

MCML Projects

MCML projects use this methodology. The Model in this case is created with any .NET language (C# is the most common, but you can also use VB.NET). This allows you to perform all of your real work in a high-powered programming language that you may already know.

The view – the user-interface you use to access your model – is created in the Media Center Markup Language.

Talking

The most important thing when developing a model-view application is realising how the two separate components communicate to each-other. The view has to be able to get information out of the model so it has something meaningful to show the user.

MCML programs communicate by using object properties.

They can access any public properties of the objects you create. So, for example, the text you use in a button in your user interface can be taken from the ‘YourObject.ButtonName’ property in C# or VB.NET

Why Separate

Many people immediately ask ‘why’ when shown this model. There are a few good reasons to keep these two elements at arms length from each-other.

            Multi-Team Development

            If you agree on an object/model structure, it is possible to have to completely independent teams working on the same project – one team on interface development, the other writing the model code. Since you do not need to directly access your user-interface controls in your model code (which is required for most other styles of development other than model-view), model developers don’t need to worry about the user interface – giving the UI developers creative freedom as well.

            Ease of Changes

            Of course with your UI being separate, you will find that making user interface changes is much simpler. You no longer have to edit your resource and your code – you simply change the MCML resource, and you’re done. Of course, changes to the model (eg. changing the public properties of your .NET object) may require changes to the MCML code.

            Flexibility

            Keeping the code away from the interface also allows you to develop radically new and different interfaces for the same code – without having to change a thing. This level of flexibility is impossible with other systems. And there is the faint chance that some day – as MODO and similar .NET enabling projects become popular – your .NET code will be able to function in other Media Center environments such as MythTV, allowing you to use the same code but with a different UI mechanism.

Hopefully, this will give you the idea of how everything works as we start working in MCML.