Dynamic.Trader: a WPF demo for the Dynamic.Data reactive collections library

A demo built to be read, not to be deployed

Dynamic.Trader is a WPF demo application. The description says it shows off dynamic data and reactive extensions, and the README is explicit about the intent: it exists to show how Dynamic Data works, and to help people get up and running, and the code behind each screen has been made as simple as possible so it is easy to follow.

That framing matters, because a demo application and a sample library are different things. This one is the former. It is a running desktop app with a menu of scenarios, each one demonstrating a technique, and the menu links directly to the code behind it so a reader can move between the running app and the source without leaving the project.

The library underneath is Dynamic Data, a portable class library which brings the power of reactive extensions to collections, and its code base lives in the DynamicData repository. The homepage for the project is dynamic-data.org, and most of the example screens have been written about on that blog.

The audience is a .NET developer evaluating Dynamic Data or learning how reactive collection binding works in practice, particularly in a WPF context where the observable collection binding is the point. It is not a trading application to run against a market, and nothing in the repository suggests it is meant to be.

The project is credited to RolandPheasant, and the README thanks the projects behind MahApps and Dragablz, the WPF control libraries that made the demo look the way it does.

One pipeline that produces the live trades view

The centrepiece of the README is a single pipeline and the animated capture of what it produces. The whole live trades view is assembled from a source of trades, a filter, a transform, a sort, a dispatcher hop, and a binding:

var loader = tradeService.All
    .Connect(trade => trade.Status == TradeStatus.Live) //prefilter live trades only
    .Filter(_filter) // apply user filter
    .Transform(trade => new TradeProxy(trade),new ParallelisationOptions(ParallelType.Ordered,5))
    .Sort(SortExpressionComparer<TradeProxy>.Descending(t => t.Timestamp),SortOptimisations.ComparesImmutableValuesOnly)
    .ObserveOnDispatcher()
    .Bind(_data)   // update observable collection bindings
    .DisposeMany() //since TradeProxy is disposable dispose when no longer required
    .Subscribe();

Every stage is doing one job, and the comments in the source name each one. Connect applies a pre-filter so only live trades enter the stream at all, Filter applies whatever the user has selected in the UI, Transform wraps each trade in a TradeProxy with a parallelisation option of ordered and a level of five, Sort orders by timestamp descending with a sort optimisation that compares immutable values only, and ObserveOnDispatcher moves the work onto the dispatcher.

Bind then updates the observable collection bindings, which is where the WPF side of the story sits, and DisposeMany disposes the TradeProxy objects when they are no longer required, since the proxy is disposable. Subscribe at the end is what starts the pipeline.

The most interesting part for a newcomer is Transform. Because it runs in parallel, the ordering of the results is not the order the source produced, and the ParallelisationOptions with ParallelType.Ordered and a level of five is what preserves order while still spreading the work. That is the sort of detail the demo exists to make visible.

Grouping trades by currency pair and aggregating positions

The second example is about aggregation, and it shows a different way of using the same library. A live trade stream is grouped by currency pair, transformed into a position object, sorted ascending, observed on the main thread, and bound to the view:

 var loader = tradeService.Live.Connect()
            .Group(trade => trade.CurrencyPair)
            .Transform(group => new CurrencyPairPosition(group))
            .Sort(SortExpressionComparer<CurrencyPairPosition>.Ascending(t => t.CurrencyPair))
            .ObserveOn(schedulerProvider.MainThread)
            .Bind(_data)
            .DisposeMany()
            .Subscribe();

The interesting half is what happens inside the CurrencyPairPosition class, which connects to the cache of trades grouped by currency pair and uses QueryWhenChanged to recompute a position whenever the group changes:

	tradesByCurrencyPair.Cache.Connect()
			.QueryWhenChanged(query =>
			{
				var buy = query.Items.Where(trade => trade.BuyOrSell == BuyOrSell.Buy).Sum(trade=>trade.Amount);
				var sell = query.Items.Where(trade => trade.BuyOrSell == BuyOrSell.Sell).Sum(trade => trade.Amount);
				var count = query.Count;
				return new TradesPosition(buy,sell,count);
			})
			.Subscribe(position => Position = position);

QueryWhenChanged is the mechanism that makes this an aggregation rather than a projection. Instead of recomputing the totals on every incoming trade, the query is evaluated only when the underlying group changes, and the result is pushed into a TradesPosition holding the buy total, the sell total and the count.

The distinction between ObserveOnDispatcher in the first example and ObserveOn with an explicit scheduler provider in the second is also visible here. The first relies on the library's dispatcher, the second names the main thread scheduler from a scheduler provider, which is the pattern you would use when the WPF thread context matters.

Building the demo on Windows with Visual Studio

There is no package manager step here. The README gives a four step procedure, and the first is to press Download Zip, unpack it and open Dynamic.Trader.sln. Then ensure NuGet Restore is enabled, set Trader.Client as the startup project, and press F5.

Two details in that list carry the real information. NuGet Restore has to be enabled, because the demo depends on packages that are restored rather than vendored, and the solution contains more than one project, including the domain layer, so the startup project has to be chosen explicitly rather than relying on a default.

The repository layout matches that. There is Dynamic.Trader.sln at the root, a Trader.Client directory for the WPF application itself and a Trader.Domain directory for the trading model, a Docs directory, an Images directory holding the animations used in the README, plus Directory.Build.props, Directory.build.targets, global.json and an appveyor.yml for continuous integration. The build status badge in the README points at an AppVeyor project for the master branch, so the project was built on a continuous integration server as well as on a developer's machine.

The presence of global.json and Directory.Build.props means the build has pinned expectations, since global.json fixes the SDK version the solution expects and the props file centralises common MSBuild settings across the projects. If your Visual Studio installation has a different SDK set, that is the first thing to check when the solution fails to load or build.

A menu of examples, each linked to its own source

The demo is organised as a menu of examples rather than as a single application flow, and the README shows the menu with links to the code behind each entry. That structure is the pedagogical device that makes this project work.

A reader can open the app, pick a scenario, watch what happens on screen, and then open the specific file that produced it. The code behind each screen is kept as simple as possible for exactly this reason, and most of the screens have been written about in blog posts on dynamic-data.org, so there is usually a longer explanation available for whichever technique is on screen.

The README also mentions that there are examples showing how to integrate with ReactiveUI, alongside the Dynamic Data examples themselves, and that there are many more examples beyond the ones shown. Dynamic Data is a library about collections, and ReactiveUI is a library about the view model side of the same reactive world, so the pairing is a natural way to show the two working together in a desktop application.

The interface itself is built on MahApps and Dragablz, the WPF control library projects the README credits for making the demo look good. That is worth knowing if you plan to reuse the UI code, because it means the visual layer depends on two external control libraries as well as on Dynamic Data itself.

What this repository cannot tell you

There are real limits to what a demo can answer, and they are worth naming before you adopt it as a reference.

First, it is a demo and not a library. Dynamic Data itself lives in the DynamicData repository, and that is where the API contract, the versioning and the release process are. What this repository offers is a set of worked examples with a running application around them. If you are making an adoption decision, you are evaluating the other repository and using this one as a companion.

Second, there is no release history. The repository publishes no GitHub releases, and the last push was on 2026-04-14. The README does say that the examples are being regularly maintained and invites you to download again to see more examples, but the commit record is the harder fact to plan around, and it means you should treat the code as a fixed snapshot rather than a moving target.

Third, the licence is not stated for this repository. The description is a WPF demo, and it builds on Dynamic Data, which is open source, but the licence file that would tell you exactly what you may do with this particular repository is not identified in the project metadata. Anyone planning to reuse the code in a product needs to resolve that before shipping it, and the practical route is to use the demo as a reference and write your own code.

Fourth, it is Windows only. A WPF application with F5-to-run instructions and a Visual Studio workflow does not build or run on Linux or macOS, so the demo cannot be used directly to evaluate Dynamic Data on a non-Windows development machine.

Editorial conclusion

Adopt Dynamic.Trader as a reading reference if you are evaluating Dynamic.Data or learning reactive collections, since each screen is a self-contained example with a link to its code behind. Do not adopt it as a production trading client, as it is a demo, and do not expect a maintained codebase, because the last push was on 2026-04-14, the repository has no tagged releases, and the licence is not stated. Verify first that your Visual Studio and .NET versions match the ones pinned in global.json and Directory.Build.props, that NuGet Restore is enabled before you build, and that Trader.Client is set as the startup project, since the application targets Windows and WPF.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. RolandPheasant/Dynamic.Trader on GitHub