Poor man Map/Reduce in MongoDB and a cool non-feature

I’m working with Alessandro (from Codice/Plastico) at a really interesting customer (not only for the frequent fashion shows ;-) ) on a really interesting project where we are applying lots of Domain Driven Design concepts, using Event Sourcing and CQRS strategies where everything is persisted on MongoDB.

Being used to all the built-in features provided out-of-the-box by RavenDB the initial daily usage of MongoDB has been quite full of friction (at least for me). From a certain point of view there is a non-feature of MongoDB that after all is a big win when used in a domain driven design based project: “the missing linq provider”, and I have to admit that “I’m lovin’ it” <cit.>.

The C# driver we are using (v1.3) has no built in support for linq queries, the v1.4 introduce the linq support, this basically means that every query you issue to the database looks like the following statement:

Query.EQ( "Author", authorId )

Or a sort by clause looks like:

SortBy.Descending( "PostedAt" )

As you can see it simply means that you have to revert back to “strings” backed into the code, but this let us achieve really really easily…

CQRS

Take a look at the following aggregate that represents a message on a board (something really similar to a Facebook wall):

public class Message : AggregateRoot
{
	[BsonElement( "Board" )]
	private OwnerBoard board;
 
	[BsonElement( "Sender" )]
	private Sender sender;
 
	[BsonElement( "Text" )]
	private string text;
 
	[BsonElement( "PostedAt" )]
	[BsonRepresentation( BsonType.Document )]
	private DateTimeOffset postedAt;
 
	[BsonElement( "Attachments" )]
	private IEnumerable<Attachment> attachments;
 
	readonly IMessageBroker broker;
	readonly IOperationContext context;
	readonly IMongoRepository mongo;
 
	private Message( IMessageBroker broker, IMongoRepository mongo, IOperationContext context )
	{
		this.broker = broker;
		this.context = context;
		this.mongo = mongo;
	}
 
	internal void InitializeMandatoryParameters( OwnerBoard board, Sender sender, string text, IEnumerable<Attachment> attachments )
	{
		this.postedAt = DateTimeOffset.Now;
		this.board = board;
		this.sender = sender;
		this.text = text;
		this.attachments = attachments;
 
		this.Save( new MessageCreated( this.context.GetCurrentUserView(), this.Id ) );
	}
 
	void Save( DomainEvent @event )
	{
		this.mongo.Save( this, true );
		if( @event != null ) this.broker.Broadcast( @event.AsMessageFrom( this ) );
	}
}

There is one really really important thing to notice: no public properties, well no properties at all, only behaviors (I’ve dropped the majority of the code).

What happens is that there is a factory (a MessageFactory), tightly coupled with the message class that is responsible for the creation of a new message (and is the only one that has access to the InitializeMandatoryParameters internal method, since we are in an event source based scenario with no transaction support every single time the state of an aggregate changes the aggregate must be consistent and will self save it's own state, notifying (using a domain event) the outside world that something has happened (in the past and asynchronously).

Now, given the serialization/deserialization nature of a document database (not only MongoDB in this case) we can now issue a query like the following:

var messages = mongo.Find<MessageView>
(
	query: Query.EQ( "Sender.Id", sender ),
	sortBy: SortBy.Descending( "PostedAt.DateTime" )
);

What we achieved is that we now have a projection of the Message aggregate, a read-only projection, just for the query part of the CQRS process, auto-magically handled by the database serialization provider giving only a bunch of conventions:

[BsonIgnoreExtraElements]
public class MessageView
{
	public String Id { get; private set; }
 	public OwnerBoard Board { get; private set; }
 	public Sender Sender { get; private set; }
 	public string Text { get; private set; }
 	public IEnumerable<Attachment> Attachments { get; private set; }
}

This class is automatically mapped to the correct MongoDB structures because the naming of the properties matches the BsonElement(s) on the aggregate. The cool thing is that when you have the data in the shape you need you do not need to issue complex queries :-)

Poor man Map/Reduce

The above sample is basically a projection, we simply need a subset of the data held by the aggregate and the sample above is the easiest way to go with MongoDB; but what happens if you need to aggregate data to produce a different shape that merge data into a new (read-only) structure, a sort of materialized view, or in no-sql language, a Map/Reduce?

Given the fact that we are using an event sourcing based approach is really easy to have a domain event handler whose role is to transform the data, each time they change, in the required shape.

Easy peasy :-) without the need to deal with the JavaScript implementation of the MongoDB Map/Reduce.

.m

Toyota Auris HSD Full Hybrid

Some years ago I’ve been on the Lexus of my dear friend Nicolò for a short trip and I was fascinated by the Toyota Hybrid technology, by driving conform, by the full quietness…the sound of silence.

After some years I did it, I bought an hybrid car:

I cannot effort a Lexus but a Toyota Auris HSD Full Hybrid is in the range of my pocket so I just bought one. The next week the car will be in my hands ready to drive me to Perugia for the RavenDB training.

Stay tuned, a trip of 924km as a start will be a good test.

.m

RavenDB: I want my data!

Take a look also at Gian Maria’s posts on the topic.

As I’ve said during my talk about RavenDB at the UgiAlt.Net conference one of the most important concept of a document database and in this case of RavenDB is the concept of indexing. An index is the only way (well, not really) to read your data from the database, without an index the database is fairly useless.

As all the databases out there RavenDB offers two main way to access your own data:

• Load data: load expects to search data using the identifier of the requested data, a load operation does not requires an index to be performed nor it is affected by the indexing process; once the data is written the same data, using its identifier, is immediately accessible using a load operation;
• Query data: querying is the art of searching data given a set of criteria, in a document database a query requires an index to be executed, in RavenDB does not exists the concept of full table scan, basically because table does not exists and because it is a non sense to scan the entire database and for each document the entire document searching for something that matches the given criteria;

Personal Statement

The fact that the concept of a full table scan does not exists, from my point of view, is one of the coolest features a database (note that I’ve not specified “document” here…) can provide…

What the hell are you saying?

as I have already said document databases perfectly suites the domain driven design world (once again I’m not saying that relational databases does not suite, it is not a fight) or much better tend to drive the developer into the DDD world. In this travel the developer is forced to think about the shape of the data and to think about the usages of the data because the database requires the developer to define the indexes to query the stored data and indexes are directly related to data usages.

Unlike relational databases where exists the concept of “normal form” of data in the document world there isn’t any rule on how to design the shape of the data and such lack can be considered a feature (once you gained a bunch of experience) because you are forced to think at the shape in term of scenarios and use cases and not only in term of good data design; on the other side relational databases tends to follow the developer always returning data even if the shape is the worst possible shape…obviously the developer will be punished at runtime once the application is in production…too late my dear.

Let’s go back to the topic of the post…

Indexes

I suppose we all have understood that indexes are a requirement in a document database, but what are indexes? the most trivial compare can be done with an hash table where the indexed data is the key and the value is the document that matches those data: too simplistic but gives the idea.

In the next post we’ll start diving into the indexing concepts of RavenDB, looking at:

• Simple Indexes (or Map);
• Index Projection;
• Map/Reduce;

.m

Radical - UI Composition: inject content at runtime

We have seen some of the concepts behind the UI Composition features offered by the Radical framework, remember that all these concepts aims to be cross platform, currently WPF and Silverlight are supported, next will be Windows 8 Metro and Windows Phone 7.

Injection

The concept is trivial: a view defines one or more “areas” where another view can be injected.

Currently it is a really easy operation, as we have seen the MainView simply defines some regions and the MainViewModel has nothing special:

class MainViewModel : AbstractViewModel
{
 
}

Really nothing, on the other side the view that we want to inject (that is the driver of the injection) is defined as follows:

public partial class SampleContentView : UserControl
{
	public SampleContentView()
	{
		InitializeComponent();
	}
}

Even here nothing special, but…let us give a wider look:

namespace Radical.Presentation.Samples.Presentation.Partial.SampleContentRegion
{
	public partial class SampleContentView : UserControl
	{
		public SampleContentView()
		{
			InitializeComponent();
		}
	}
}

Take a look at the namespace:

• everything that is in the “*.Presentation.Partial.*” (it’s a modifiable convention) namespace will be considered a region content;
• the last token of the namespace, in this sample “SampleContentRegion” will be considered as the name of the region;

If this convention cannot satisfy the user needs (and actually there are a lot of cases where the convention cannot be used) the view to inject can be defined as follows:

[InjectViewInRegion( Named = "InnerContentRegion" )]
public partial class InnerContentView : UserControl
{
	public InnerContentView()
	{
		InitializeComponent();
	}
}

Using the InjectViewInRegion attribute.

Control is everything

What happens if we want to have manual control over the injection process? Simply intercept it :-)
Inside the framework the process is governed by a message (ViewModelLoaded) broadcasted by the message broker, so just handle the message and do whatever you want with your own logic:

class MainViewModelLoadedHandler : MessageHandler<ViewModelLoaded>, INeedSafeSubscription
{
	readonly IConventionsHandler conventions;
	readonly IRegionService regionService;
 
	public MainViewModelLoadedHandler( IConventionsHandler conventions, IRegionService regionService )
	{
		this.conventions = conventions;
		this.regionService = regionService;
	}
 
	protected override bool OnShouldHandle( ViewModelLoaded message )
	{
		return message.ViewModel is MainViewModel;
	}
 
	public override void Handle( ViewModelLoaded message )
	{
		var view = this.conventions.GetViewOfViewModel( message.ViewModel );
		if( this.regionService.HoldsRegionManager( view ) )
		{
			var manager = this.regionService.GetRegionManager( view );
 
			manager.GetRegion<IElementsRegion>( "MainMenuRegion" )
				.Add( new MenuItem()
				{
					Header = "Injected in main menu",
					Command = DelegateCommand.Create()
								.OnExecute( o =>
								{
									MessageBox.Show( "Clicked!" );
								} )
				} );
 
			manager.GetRegion<IElementsRegion>( "FileMenuRegion" )
				.Add( new MenuItem()
				{
					Header = "Injected in File menu",
					Command = DelegateCommand.Create()
								.OnExecute( o =>
								{
									MessageBox.Show( "Clicked!" );
								} )
				} );
		}
	}
}

Note: Simply dropping a class like that in the “*.Messaging.Handlers” namespace defines it as a message handler that will be automatically subscribed to the specified message.

What happens?

1. Inheriting from MessageHandler<TMessage> defines that the class is a message handler of the given type TMessage;
2. The INeedSafeSubscription interface is a empty marker interface that declares to the message broker that we want to be invoked in the main thread using the dispatcher;
3. OnShouldHandle is a easy way to tell to the message broker that we are not interested in handling a specific message, the broker calls OnShouldHandle on every handler of the given message type before calling “Handle”;
4. Handle is where the real work happens:
   1. given the ViewModel use the conventions the retrieve a reference to the view;
   2. verify if the view has an associated region manager;
   3. retrieve a reference to the region manager of the view;
   4. use the region manager to access the region by name;
   5. add the desired content to the region;

Disclaimer:

Currently all what seen in this post is publicly available on NuGet using a couple of pre-release package.

.m

Radical - UI Composition: concepts

Cool…but what the hell is it?

it is a Window… :-) whose xaml (MainView) is defined as follows:

<Window ...>
	<Grid>
		<Grid.RowDefinitions>
			<RowDefinition Height="Auto" />
			<RowDefinition Height="*" />
		</Grid.RowDefinitions>
 
		<Menu ... rg:RegionService.Region="{lrg:MainMenuRegion Name=MainMenuRegion}">
			<MenuItem Header="File" rg:RegionService.Region="{lrg:MenuItemRegion Name=FileMenuRegion}">
				<MenuItem Header="Sub Item" />
			</MenuItem>
		</Menu>
 
		<ContentPresenter ... rg:RegionService.Region="{rg:ContentPresenterRegion Name=SampleContentRegion}" />
	</Grid>
</Window>

(“…” content removed for clarity)

The UI is really, really simple but defines 3 different regions where content can be injected at runtime.

What does it mean “inject content at runtime”?

First of all let us take a look at what the xaml does: we are using the “Region” attached property, provided by the Radical framework, to attach to standard WPF UI elements 3 different types of region, each one created by a specific markup extension and uniquely identified, within this view, by its name.

Regions

Radical offers some built-in region types:

As you can see from the diagram there are some interfaces, and already built generic abstract classes ready for inheritance, that defines the 3 (well 4…) main region concepts:

IRegion: the IRegion is the mother of all regions carrying the basic information required such as the region name and a reference to the hosting view, its concrete implementation is a markup extension that provides to the inheritors all the plumbing required the WPF; An IRegion, nor a Region<T>, can be directly used as a concrete region, the real regions are the followings:

1. IContentRegion: a IContentRegion is a region that is capable of hosting one single content at a time, at runtime the content can be replaced whenever is needed using the Content property, that directly maps to the Content property of the element this region is attached to; An obvious and built-in implementation of this type of region is the ContentPresenterRegion that can be attached to any WPF ContentPresenter;
2. IElementsRegion: a IElementsRegion is built to host more than one element, where all the elements are all visible at the same time, basically it is a collection of “region content”, one built-in implementation is the PanelRegion that can be attached to any panel type, but it is really easy to built your own ItemsControlRegion that can be attached to any ItemsControl; in the Radical samples there is a MainMenuRegion and a MenuItemRegion that are built to host MenuItem(s) in the Menu WPF element and in the MenuItem WPF element;
3. ISwitchingElementsRegion: a ISwitchingElementsRegion, as its ancestor, is built to host more than one element at a time and adds the concept of active element, that is automatically tracked for changes. A real world sample of this type of region is a TabControlRegion where where runtime region elements will be TabItem(s) that the user can click to activate;

The abstract classes are generic classes ready to be “closed around” the UI element for which we are building the specialized region. Here is the full code required to build a new region type for menus:

public class MainMenuRegion : ElementsRegion<Menu>
{
	public MainMenuRegion()
	{
 
	}
 
	public MainMenuRegion( String name )
	{
		this.Name = name;
	}
 
	protected override void OnAdd( System.Windows.DependencyObject view )
	{
		this.Element.Items.Add( ( MenuItem )view );
	}
 
	protected override void OnRemove( System.Windows.DependencyObject view, RemoveReason reason )
	{
		view.As<MenuItem>( e =>
		{
			if( this.Element.Items.Contains( e ) )
			{
				this.Element.Items.Remove( e );
			}
		} );
	}
}

Really, really easy.

In the next post we’ll see how all this stuff can be used to inject content at runtime.

.m

Radical.Windows.Presentation: runtime conventions

We have already introduced some of the runtime conventions used by Radical.Windows.Presentation. Radical.Windows.Presentation has also a lot of runtime conventions mainly related to two different areas:

• View – ViewModel relation;
• UI Composition;

Here they are:

public interface IConventionsHandler
{
	Func<Type, Type> ResolveViewModelType { get; set; }
 	Func<Type, Type> ResolveViewType { get; set; }
 	Func<Object, Window> FindHostingWindowOf { get; set; }
 	Predicate<DependencyObject> ViewHasDataContext { get; set; }
 	Action<DependencyObject, Object> SetViewDataContext { get; set; }
 	Func<DependencyObject, Object> GetViewDataContext { get; set; }
 	Action<DependencyObject, Object> AttachViewToViewModel { get; set; }
 	Func<Object, DependencyObject> GetViewOfViewModel { get; set; }
 	Func<DependencyObject, Action<DependencyObject>, DependencyObject> TryHookClosedEventOfHostOf { get; set; }
 	Func<FrameworkElement, Boolean> IsHostingView { get; set; }
 	Action<DependencyObject> AttachViewBehaviors { get; set; }
}

ResolveViewModelType

The first convention is used internally by the ViewResolver and given the view type returns the ViewModel type for the given view, the default behavior is that the view model is in the same namespace of the view and has the same type name suffixed with “Model” (e.g.: MainView and MainViewModel)

ResolveViewType

The ResolveViewType convention is currently under development and not used, but basically does the opposite stuff, using the same default behavior, as the ResolveViewModelType convention.

FindHostingWindowOf

This convention is currently used to find the Window that hosts a given view model, quite certainly this convention will be changed in the near future to support the fact that in Windows 8 Metro style apps a Window object does not exists.

This task is performed finding the current view of the given view model (using another convention) and then reverse walking the visual tree looking fir the first Window.

The convention accomplish two needs:

1. A view model can implement the IExpectViewClosingCallback and the IExpectViewClosedCallback in order to intercept the fact that the hosting Window is closing or has been closed and since we support UI Composition features a view model can be a view model attached to a UserControl that is runtime “inserted” into the visual tree of an existing Window;
2. The UI Composition region service, in order to satisfy the above requirement, each time setups a new region need to find the hosting window in order to attach the closing and closed events;

ViewHasDataContext, SetViewDataContext and GetViewDataContext

The ViewHasDataContext convention simply checks if the given view DataContext property is not null, this convention accepts a DependencyObject because in WPF the DataContext property is not defined on a single root object but is defined on FrameworkElement and on FrameworkContentElement.

SetViewDataContext and GetViewDataContext respectively sets and gets the DataContext of the given view.

AttachViewToViewModel and GetViewOfViewModel

Internally the Radical.Windows.Presentation MVVM and UI Composition toolkit needs to know runtime View – ViewModel relations in order to know that given a ViewModel instance the corresponding View instance is certainly a specific instance.

To achieve that the ViewResolver once has resolved both the required instances calls the AttachViewToViewModel convention in order to store the view reference in the view model instance (the view model is already stored in view instance using the DataContext property).

By design this works out-of-the-box because the AbstractViewModel type implements the IViewModel interface that has a View property internally used for this tasks. If the user does not like this behavior or cannot inherit from the AbstractViewModel type, nor implement the IViewModel interface, can replace this convention in order to store somewhere else the required relation.

The same logic is used by the GetViewOfViewModel convention that is required to retrieve the stored relation.

TryHookClosedEventOfHostOf

This is really internal and is used by the region service engine to attach the closed event of the hosting window, if any, in order to cleanup stuff when the window closes.

IsHostingView

The IsHostingView convention is internally used by the Region base class to determine if a given visual element can be considered a View.

AttachViewBehaviors

The AttachViewBehaviors convention can be hooked by the framework user if there is a requirement to attach behaviors (System.Windows.Interactivity.Behavior<T>) whenever a view is resolved by the ViewResolver.

Conclusion

As you can see this post is mainly a documentation post not so interesting, well at least for me, do not worry in the next post we’ll introduce the UI Composition features supported by Radical.Windows.Presentation.

Stay tuned.

.m