This series exists to build support around the idea of a ubiquitous .NET client application development model. This is not intended to be a final solution, but a starting point for discussion, awareness, and a sign of demand. Show your support by voting for this idea here:
Desired and Expected Qualities
In this article, we outline the desired and expected qualities for a ubiquitous .NET client application model. The purpose of this article is to not only provide a vocabulary and context of definitions used later on in subsequent articles, but to also provide a fuller meaning of precisely what we mean when we say a “ubiquitous .NET client application model.” Ubiquity and ubiquitous implies an essence and expectation of everywhere, and while that is certainly the primary expected and desired quality of what we would like to achieve, there are other technical requirements at play that should also exist in any designed (and desired) ubiquitous .NET client application model.
Below, you will find the list of these qualities in full. Please note that we consider qualities as requirements and will use these terms interchangeably. In the next post, we will be using these qualities to demonstrate that no existing client application model possesses the desired requirements to be considered a truly _ubiquitous_ .NET client application model.
Native Cross-Platform Capable
Let’s start with the easy one first. It seems as if this is a prevalent and expected requirement and capability these days. A ubiquitous client application should expect to run on workstations and desktops, as well as mobile devices and the various platforms that support each of these form factors. The major players and expectations are:
- iOS / Macintosh
- Droid / *nix (Unix/Linux)
Microsoft has done a great job opening up to the different platforms outside of Windows. However, this is not the case for any of their current client application models, as all of them (with the exception of the ill-fated Silverlight) remain strictly a Windows-only affair. A ubiquitous client application model is satisfied by running on all of the major platforms outlined above. The expectation for a ubiquitous .NET client application development model is that it will be built into artifacts that will run on the target platform in a native way.
Consistent User Experience
When we speak of a ubiquitous client application model, the expectation is that its user experience is the same no matter what device or platform from which it is viewed. This is much in the same way an HTML5 web page looks and feels the exact same way no matter the browser or OS used to load and view it. In a ubiquitous .NET application, the expectation is that this quality is preserved, and all clients everywhere — no matter the platform or device — provide the exact same user experience to the user. In addition to consistency, this offers strength and value to the model at large, as it asserts its own unique perspective on user interaction and this reinforces its brand in the marketplace (much like HTML5).
Xaml is probably one of Microsoft’s greatest inventions and it really does not seem to get the acclaim it deserves. When we speak of Xaml, we speak of the Xaml model that is found in Windows Presentation Foundation and Silverlight 5 as the model to compare all other subsequent Xaml models. Both of these client application models feature the best and most powerful Xaml capabilities in comparison to any of the other client application models out there today. It is also important to note that Xaml is not just a mechanism for defining user interface elements, but a powerful and expressive mechanism to describe any .NET object in very elegant and creative ways. It is a serialization mechanism with concepts that are not found in any other serialization framework, and this is why it is so powerful and fun to work with as a developer. In addition to serialization, Xaml development benefits from strong tooling and designer support found in Visual Studio. Any ubiquitous .NET client application model should be powered by these mature and tested capabilities and features that Xaml affords.
Object Serialization Congruence
Serialized congruence is a quality that describes the intent of an object that is described and serialized via a markup language. When we say that an object has serialized congruence, we mean that the object that is created in memory is the same as the object that is defined and described in the serialized file. Another way of looking at this quality is that the external matches the internal. For example, consider the following markup:
When this object has been deserialized and viewed in memory, we should expect an object of type Apple that was created and stored there, not an Orange or Banana. That is, there is a 1:1 correlation between what was defined and described in the serialized file versus what we ultimately find in memory. Because of this, the class definition of the object becomes its schema. This is very helpful for both tooling and design (not to mention the developer). Additionally, this also optimizes resources as now a developer (and tools) only need to know about two artifacts: the serialized data file and the class file as its schema.
Now consider another example that might create an Apple in memory after it has been serialized:
<object add="Fruit" type="Apple" />
In this case, special logic exists somewhere that ultimately does a lookup on a string to determine the action to perform (activate an object). A subsequent attribute lookup on the “type” property is also used to resolve the type used for activation. The result is ultimately the same (an Apple is created) as the previous example, but in this example, the data provided here does not accurately reflect the nature of this ultimate result. This is not a 1:1 correlation of the describing data to the desired initialized object and is therefore not congruent.
Additionally, a separate file must now be created and stored that defines the schema of this data file, and kept in sync with the object that it is defining. This produces three artifacts: the serialized data file, the class it is defining, and the schema used to define the data file. This is costly from a resource perspective (more bytes and files on disk) and also from a developer perspective, as developers now have to locate, link, and keep track of additional unnecessary files when managing data definitions of objects when utilizing this design.
Now, let’s move from fruits to a more practical example using a client-side component. In particular, we will use an object that can be used to display elements within it:
This makes sense and seems congruent. We are defining a DockPanel object and when the serialization mechanism processes the data (xml) and loads the object in memory, we should expect to see a DockPanel.
Now, let’s see another example of how this object might be defined in another client application model, specifically HTML5:
By now the example and premise should be clear. We are intending to describe a DockPanel, but are creating an object in memory that is not this object, but more than likely behaves like a DockPanel. This is not congruence, as what is defined in data (xml — or the external) is not ultimately what is created and loaded into memory (the internal). This is again costly on two different fronts: in the tooling built accounting for this design, and with the developer having to comprehend and accurately understand its conceptual nature.
At this point, it should be obvious that Xaml-based application development caters to this requirement perfectly, as objects are accurately defined and serialized with absolute congruence.
Holistic Development Consistency
Finally, we have the issue of holistic development consistency. This goes along with the requirement of cross-boundary artifacts and assemblies. This occurs when the same naming and development guidelines are applied equally to all projects within a solution uniformly. That is, objects that are defined and used in the server tier use the same development guidelines that are used in the client tier. Guidelines are rules that apply to concepts such as naming, capitalization, member definitions, and type definitions. .NET has a very comprehensive set of guidelines and they can be found here.
In the next post of this series, we will search for the qualities defined above in all the known major and upcoming .NET client application models. Through this exercise, we hope this will help demonstrate what we are after when we envision and articulate a ubiquitous .NET client application model, while also underscoring that no one model can truly be considered ubiquitous in the current market climate.
Show Your Support
If you like the idea of a ubiquitous .NET client application development model, please take the time and let Microsoft know by voting for this idea on UserVoice: