> For the complete documentation index, see [llms.txt](https://docs.zongsoft.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.zongsoft.com/documentation/en/framework/core/components.md). # Zongsoft.Components Responsibilities of the Zongsoft.Components namespace and its subnamespaces. `Zongsoft.Components` is the component model namespace in the core class library, covering basic builtins such as commands, execution pipelines, handlers, filters, converters, supervised objects, [workers](https://github.com/Zongsoft/framework/blob/main/Zongsoft.Core/src/Components/IWorker.cs), identifiers, and event exchanges. Its goal is not to provide a specific business capability, but to provide a set of runtime abstractions for business objects in different fields that are composable, extensible, and reusable by the host. ## Main Responsibilities * Define component identities, aliases, weights, named objects, and service descriptions so components can be discovered, described, and selected. * Provides command mode, command tree, command expression parsing, command exit and parameter binding to trigger business actions across domains and with low coupling. * Provides execution pipelines, handlers, and filters to organize context, execution logic, and cross-cutting features into scalable execution units. * Provides runtime component modes such as [worker](https://github.com/Zongsoft/framework/blob/main/Zongsoft.Core/src/Components/IWorker.cs), monitor, weighted selector, and attempt tracker for background tasks, status observation, and failure control. * Provide common converters, state machines and component feature extensions to reduce repeated implementation of infrastructure code. ## Command Mode The command pattern is one of the most commonly reused component models across modules in `Zongsoft.Components`. It describes an operation as a command expression, and `CommandExecutor` locates `CommandNode` in the command tree, creates `CommandContext`, and calls the `ICommand` instance. Commands are not tied to a specific container or host: the same set of commands can be called directly by a background service or web program, or loaded as interactive commands by a terminal host. This mode is particularly suitable for cross-domain calls. The caller only needs to know "what action to perform" and "which parameters to pass", and does not need to refer to the specific service interface. For example, SMS sending, queue subscription, file operation, configuration reading and other capabilities can all be entered into the unified execution pipeline through command expressions. The specific implementation of general commands is mainly located in the `Zongsoft.Commands` project, and the command interaction in the terminal program is implemented by `Zongsoft.Terminals` based on the same set of models. {% content-ref url="/pages/4te0WYPVMIJCKyvvELTh" %} [Commands](/documentation/en/framework/core/components/commands.md) {% endcontent-ref %} ## Sub Namespace | namespace | Description | | -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `Zongsoft.Components` | [Core](https://github.com/Zongsoft/framework/tree/main/Zongsoft.Core) types of command models, such as `ICommand`, `CommandBase`, `CommandContext`, `CommandNode`, `CommandLine`, and `CommandExecutor`. | | `Zongsoft.Components.Commands` | Built-in component commands implemented based on the command model, such as [worker](https://github.com/Zongsoft/framework/blob/main/Zongsoft.Core/src/Components/IWorker.cs) start, stop, pause, resume and status query commands. | | `Zongsoft.Components.Converters` | Common converters for Boolean, enum, version, schema, etc. | | `Zongsoft.Components.Features` | Retry, Fallback, Breaker, Throttle, Timeout and other execution feature models. | | `Zongsoft.Components.States` | State machine, state diagram, state context, state handler and state flow. | ## Type
Identity: Object identification abstraction and unified identification value.Identifiers
AliasAttribute: declare aliases for types, members, parameters, etc.Aliases
Command: low-coupling cross-domain calling model, command line parsing and terminal interaction foundation.Commands
Events: event description, event location, event exchange, and plugin architecture handler mounting.Events
Worker: A background worker model that can start, stop, pause, and resume.Workers
Handler: handler abstraction, selector, and plugin architecture handler collection.Handlers
Filter: filter interface that performs pre- and post-processing around the context.Filters
Superviser: An observation, failure, and recovery model for supervisory objects.Superviser
Weighter: Smooth weighted polling selector.Weighted Selection
Discriminator: Let the container identify subcollections or target types by content.Discriminators
Attempter: Failed attempt count statistics and lock window control.Attempt Tracking
Converters: Commonly used type converters at the component layer.Converters
State machine: state diagram, state context, state handler and state flow.State Machine
execution pipeline: combines Executor, context and Feature attributes into an execution unit.Execution Pipeline
## Related Resources * [Components source code directory](https://github.com/Zongsoft/framework/tree/main/Zongsoft.Core/src/Components) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.zongsoft.com/documentation/en/framework/core/components.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.