My Thoughts on an MVVM-friendly DomainDataSource

The DomainDataSource (DDS) could be a great example of an aggregate component. It has a simple public API and does a lot of awesome things at the flip of a switch. The only problem with the thought is there’s little-to-no aggregation going on. All the composition that occurs is hidden behind a wall of internal API. This is especially frustrating for MVVM development where a lot of what the DDS does is not as useful.

In creating an MVVM-friendly DDS we have to figure out the primary components and how they work together. Here’s a rough sketch of where I imagine this design will go. This pattern is so well-worn, I’d almost feel guilty deviating from it.

Even with something so familiar as the base, there are a ton of features to pack in. Here are the set I considered with a few ‘cut’ lines drawn through for priority. High-priority features are the bare essentials for an MVVM-friendly DDS. Medium-priority features are great, but not critical. Low-priority features are things I’ll consider but will probably never get to. Please let me know if you think something needs to be added, removed, or moved to a different priority level.

   ===== High Priority =====

Source: EntitySet – Using an EntitySet with the rest of the features.
Source: EntityCollection – Using an EntityCollection with the rest of the features.
Source: Read-Only Collection – Using a read-only collection with the rest of the features.
Source: Mutable Collection – Using a mutable collection with the rest of the features.

Server: Sorting – Applying sorting to the data on the server.
Server: Grouping – Applying grouping to the data on the server.
Server: Paging – Applying paging to the data on the server.

Editing: Adding – Adding a new Entity to the source collection.
Editing: Removing – Removing an Entity from the source collection.

Testing: Component Base Classes – Abstract base classes for individual components.

Designer: View – Any view property can be set in xaml using a designer.

Quality: Toolkit – High-quality, partially-supported features.

   ===== Medium Priority =====

Client: Filtering – Applying a filter to the source collection on the client.

Server: Filtering – Applying a filter to the data on the server.

Query: Dynamic ‘And’ – Creating an EntityQuery using ‘And’ from a dynamic set of filters on the client.
Query: Dynamic ‘Or’ – Creating an EntityQuery using ‘Or’ from a dynamic set of filters on the client.
Query: Nested – Creating an EntityQuery with nested clauses from a dynamic set of filters on the client.
Query: Shaping– Creating an EntityQuery from a dynamic set of sorts, groups, or paging parameters on the client.

Other: Strong-Typing – Strongly-typed API for Entity interaction.
Other: Source Code – Feature source code.
Other: Samples – Feature samples.

Quality: Framework – High-quality, fully-supported features.

   ===== Low Priority =====

Client: Sorting – Applying sorting to the source collection on the client.
Client: Grouping – Applying grouping to the source collection on the client.
Client: Paging – Applying paging to the source collection on the client.

Loading: Auto – Tracking changes that affect the query and automatically reloading.
Loading: Timed – Reloading based on a timed interval.
Loading: Incremental – Incrementally loading a large data set in smaller blocks.

Testing: Top-level Interfaces – Interfaces for the top-most aggregate objects.
Testing: Component Interfaces – Interfaces for individual components.

Designer: Filtering – Defining filters in xaml using a designer.
Designer: Sorting – Defining sorts in xaml using a designer.
Designer: Grouping – Defining groups in xaml using a designer.

Other: Hot-Swapping – Switching between client and server data shaping during use.

Quality: Preview – Medium-quality, mostly unsupported features; as soon as possible.