I also add the following NuGet packages in this sample: jquery, jquery.ui.combined and toastr with the Install-Package command in Package Manager Console in VS2012. It is not uncommon to add RequireJs also if you will create external modules with TypeScript. Here, we will create a simple external module.
Let's look at a TypeScript file with Loggers next:
/// <reference path="TypeDefinitions/jqueryui.d.ts" />
/// <reference path="TypeDefinitions/jquery.d.ts" />
/// <reference path="TypeDefinitions/toastr.d.ts" />
// Module App.Util.Loggers
module App.Util.Loggers {
export enum LogLevel {
Information = 0,
Warning = 1,
Error = 2,
}
// Interface ILogger
export interface ILogger {
Log(message: string): void;
LogLevel: LogLevel;
}
export class BaseLogger {
private logLevel : LogLevel;
constructor(logLevel: LogLevel) {
this.LogLevel = logLevel;
}
get LogLevel() {
return this.logLevel;
}
set LogLevel(logLevel) {
if (this.logLevel != logLevel) {
this.logLevel = logLevel;
}
}
}
// Class DialogLogger
export class DialogLogger extends BaseLogger implements ILogger {
private anchorId: string;
private modal : bool;
constructor(logLevel: LogLevel, anchorId : string, modal? : bool) {
super(logLevel);
this.AnchorId = anchorId;
this.Modal = modal;
}
public Log(message: string): void {
var dialog = $("#" + this.AnchorId).dialog({
title: message,
buttons: {
Ok: function () {
$(this).dialog("close");
}
},
modal: this.Modal
});
switch (this.LogLevel) {
case LogLevel.Information:
dialog.parent().addClass("ui-icon-information");
break;
case LogLevel.Error:
dialog.parent().addClass("ui-state-error");
break;
case LogLevel.Warning:
dialog.parent().addClass("ui-state-warning");
break;
}
}
get AnchorId() {
return this.anchorId;
}
set AnchorId(anchorId: string) {
if (this.anchorId != anchorId) {
this.anchorId = anchorId;
}
}
get Modal(){
return this.modal;
}
set Modal(modal : bool) {
if (this.modal != modal) {
this.modal = modal;
}
}
}
//Class ToasterLogger
export class ToasterLogger extends BaseLogger implements ILogger {
constructor(logLevel: LogLevel) {
super(logLevel);
}
public Log(message: string): void {
switch (this.LogLevel) {
case LogLevel.Information:
toastr.info(message);
break;
case LogLevel.Error:
toastr.error(message);
break;
case LogLevel.Warning:
toastr.warning(message);
break;
}
}
}
//Class ConsoleLogger
export class ConsoleLogger extends BaseLogger implements ILogger {
constructor(logLevel: LogLevel) {
super(logLevel);
}
public Log(message: string): void {
switch (this.LogLevel) {
case LogLevel.Information:
console.info(message);
break;
case LogLevel.Error:
console.error(message);
break;
case LogLevel.Warning:
console.warn(message);
break;
}
}
}
}
The Javascript generated from the Logger.ts TypeScript file is:
var __extends = this.__extends || function (d, b) {
for (var p in b) if (b.hasOwnProperty(p)) d[p] = b[p];
function __() { this.constructor = d; }
__.prototype = b.prototype;
d.prototype = new __();
};
var App;
(function (App) {
(function (Util) {
///
As noted before, TypeScript generates this Javascript file and can also create a minified Version, in addition a sourceMappingURL is also set to give the Javascript file(s) a source map, so we can debug the TypeScript file. You edit the .ts file and edit the .ts file. TypeScript in other ways lets you work in a higher level Language than Javascript to let you work with more familiar code and also adds compilation type level safety and checking. Whenever you edit and save the .ts file, the generation of a .js, js.min and js.map files are done. Note that this can take some seconds when you work in the IDE. I expect future versions of TypeScript to have a quicker compiler. I have used TypeScript 0.9.1 in this example.
<html lang="en">
<head>
<meta charset="utf-8" />
<title>TypeScript HTML App</title>
<link rel="stylesheet" href="app.css" type="text/css" />
<script src="app.js"></script>
<link href="content/toastr.min.css" rel="stylesheet" />
<script src="Scripts/jquery-1.6.4.min.js"></script>
<script src="Scripts/jquery-ui-1.10.3.min.js"></script>
<link href="content/themes/base/jquery.ui.all.css" rel="stylesheet" />
<script src="Scripts/toastr.min.js"></script>
<script src="Scripts/Logger.js"></script>
</head>
<body>
<h1>TypeScript Logging demo</h1>
<script type="text/javascript">
function consoleLogger() {
var logger = new App.Util.Loggers.ConsoleLogger(App.Util.Loggers.LogLevel.Warning);
logger.Log("Hello from console logger!");
}
function toastrLogger() {
var logger = new App.Util.Loggers.ToasterLogger(App.Util.Loggers.LogLevel.Information);
logger.Log("Hello from toastr logger!");
}
function dialogLogger() {
var logger = new App.Util.Loggers.DialogLogger(App.Util.Loggers.LogLevel.Error, "dialog-message", true);
logger.Log("Hello from dialog logger!");
}
</script>
<div id="content">
<input type="button" value="Test console logger" onclick="consoleLogger()" />
<input type="button" value="Test toastr logger" onclick="toastrLogger()" />
<input type="button" value="Test dialog logger" onclick="dialogLogger()" />
<div id="dialog-message" style="display: none">
<p>This dialog was launched by App.Util.Loggers.DialogLogger!</p>
</div>
</div>
</body>
</html>
As you can see from the TypeScript code above, we generated Javascript where one BaseLogger class was inherited three times. We used the high level constructs of TypeScript such as:
<PropertyGroup Condition="'$(Configuration)' == 'Debug'">
<TypeScriptTarget>ES5</TypeScriptTarget>
<TypeScriptIncludeComments>true</TypeScriptIncludeComments>
<TypeScriptSourceMap>true</TypeScriptSourceMap>
<TypeScriptModuleKind>AMD</TypeScriptModuleKind>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)' == 'Release'">
<TypeScriptTarget>ES5</TypeScriptTarget>
<TypeScriptIncludeComments>false</TypeScriptIncludeComments>
<TypeScriptSourceMap>false</TypeScriptSourceMap>
<TypeScriptModuleKind>AMD</TypeScriptModuleKind>
</PropertyGroup>
Note in the Project file above, I set the TypeScriptTarget to ES5, to support Ecmascript 5 properties. I think that one must also use Properties in TypeScript
if your target audience can use it. It is, after all a more correct way of doing OOP.
[Export]
public class ExportFactoryProvider<T>
{
[Import]
public ExportFactory<T> Factory { get; set; }
}
Let's test out this ExportFactoryProvider with service locator. First let's create a part we can test. Let's say we got a simple view model:
[Export(typeof(ITestViewModel))]
public class TestViewModel : ITestViewModel, IDisposable
{
public void SayHello(string message)
{
Debug.WriteLine(string.Format("Hi {0}!", message));
}
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
private void Dispose(bool p)
{
Console.WriteLine("Disposed TestViewModel");
}
}
We can then create an instance of the TestViewModel using ServiceLocator using this:
var serviceFactory = ServiceLocator.Current.GetInstance<ExportFactoryProvider<ITestViewModel>>().Factory;
var testViewModelExport = serviceFactory.CreateExport();
MessageBox.Show("About to dispose an instance of ITestViewModel: ");
testViewModelExport.Value.SayHello("Johnny");
testViewModelExport.Dispose();
As you can see above, we must first use the ExportFactoryProvider, then call CreateExport, then use the Value property and then use the
ExportLifetimeContext<T> to control the disposing of the object from the IoC container. But as you can see, we must do some juggling to
keep a reference to the lifetime context and the instance itself. These two objects are inherently tied together. Let's create a generic class to
keep them together.
[Export]
[PartCreationPolicy(System.ComponentModel.Composition.CreationPolicy.NonShared)]
public class ExportFactoryInstantiator<T> : IPartImportsSatisfiedNotification
{
[Import]
public ExportFactory<T> Factory { get; set; }
public T Instance { get; private set; }
private ExportLifetimeContext<T> lifeTime;
public void OnImportsSatisfied()
{
lifeTime = Factory.CreateExport();
Instance = lifeTime.Value;
}
public bool DisposeOnDemand()
{
if (lifeTime == null)
return false;
lifeTime.Dispose();
return Instance == null;
}
}
You can use the class above, ExportFactoryInstantiator to create NonShared parts (object instances) via ExportFactory and via the instance created
access the Instance property to get to the actual object and use the method DisposeOnDemand, which returns true if the object was set to null during the
execution of this method. You can also see that we use IPartImportsSatisfiedNotification to await the resolution.
var anotherTestViewModel = ServiceLocator.Current.GetInstance<ExportFactoryInstantiator<ITestViewModel>>();
anotherTestViewModel.Instance.SayHello("Bob");
anotherTestViewModel.DisposeOnDemand();
Note that the instance now can be easily worked against. However, still it is a bit verbose, we can create a static method to help us with that:
public static ExportFactoryInstantiator<T> ResolveViaExportFactory<T>()
{
return ServiceLocator.Current.GetInstance<ExportFactoryInstantiator<T>>();
}
We have finally reduced the complexity of being able to dispose MEF parts on demand in our applications:
var yetAnotherTestViewModel = ResolveViaExportFactory<ITestViewModel>();
yetAnotherTestViewModel.Instance.SayHello("Joey");
yetAnotherTestViewModel.DisposeOnDemand();
To sum up, MEF 2 provides a feature where we can now dispose parts from the container on demand. This is a great improvement and will reduce the issues
around memory leaks substantially. If you have complex viewmodels, disposing a view model high up in the object graph will usually dispose all child view models, properties and so on and reduce memory usage. But always be careful when disposing objects from your container. You must be sure that the object will not be useful anymore.
In this StackOverflow thread you can also see an example of how to use a Part only when you need it, inside a using block:
Nicholas Blumhardt on using ServiceLocator and ExportFactory
As you can see, I use Nicholas Blumhardt's code as a starting point and refine it a bit to reduce complexity and tie together the Instance and provide DisponseOnDemand method. You must yourself judge when to release a part, be it a view model or some other resource. The using block are handy when you are sure you do not need the instance more than temporarily. You should consider doing that instead of importing many parts to your view model. Yes, the object creation of your view models will be quicker and yes, the execution will in fact be slower because of the need to create imported parts on demand via ServiceLocator, but at the same time, your application will keep a very low memory profile.
I haven't had the opportunity to test out the code above yet against production code, so do not use it in production without verifying its validity in for example Red Gate ANTS Memory Profiler and testing it. I would like to hear from other developers using MEF and have experienced its memory usage woes for more views about MEF. If you have also tips against efficiency and performance of MEF containers, please let us other MEF developers know.