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.