core.query.design
As part of the CQRS pattern, queries are separated from commands. This allows for efficient query execution that can be separate from the domain entity storage updated by commands. Queries are best used when a request for data is based on a set of criteria. Also, queries are beneficial for representing common query concepts such as paging and sorting.
Interface representing a query request. An instance of a query contains properties describing the criteria of the query and a reference to the result.
Marker interface identifying component that can handle a query request. The consumer defines a method with a parameter of the query it handles. Also, for the query handler method to be invoked, it must be marked with the InProcessHandler attribute.
Plugin module responsible for scanning for all IQueryConsumer concrete classes defining query handler methods. The consumers are registered with with a scope lifetime.
Interface representing a class invoked when a query is dispatched and can change the query’s state. A query filter can be executed before and/or after a query is handled by the IQueryConsumer. A query filter will be invoked before the query is handled if the IPreQueryFilter interface is implemented. Likewise, a query filter will be invoked after the query is handled if the IPostQueryFilter interface is implemented. A query filter can provide both pre and post logic by implementing both interfaces. Filters allows for specifying crosscutting logic in a central location.
Plugin module that scans for all IQueryFilter concrete classes and registers them with a scoped lifetime.
Class responsible for dispatching a query to it corresponding consumer and executing all pre and post query filters.
Central service used to dispatch queries, send commands, and publish domain events. For dispatching queries, the service delegates to the QueryDispatcher instance.