The lifecycle reveals the architecture more accurately than any class diagram: each step shows which component owns a responsibility and which contracts allow the next participant to continue.
From process startup to a persisted changeset.
The host initializes the shared runtime.
The .NET 10 process establishes environment and connection context, initializes cross-cutting services, creates the security context, and loads stable configuration in bulk. The long-lived shell makes caches, module identity, language, icons, messages, and shared datasets available once rather than per screen.
The module registry resolves an application capability.
A user action identifies a configured module. The registry determines its assembly, activation type, form or external process, identity, and permissions. Reflection activates the module without the shell referencing every business project.
The form enters the framework hierarchy.
The activated form inherits identity, messages, security context, parameter participation, MDI behavior, validation ownership, and cleanup from the appropriate ITSFrm base. An entity module receives its view and editor relationships without recreating shell integration.
The dynamic control tree is constructed.
CtrlEdtrGrp or a configured composite reads its definitions. Aliases resolve to current CLR types; controls are instantiated, named, styled, docked, and attached recursively. The controller indexes identities and wires declared data, filtering, command, and context relationships.
A named data request collects context.
The request declares required parameters. SC contributes user scope first; the form, view, filters, current entity, selection, and relationship controls contribute the values they own. The invocation trace prevents a cycle from re-entering the same participant indefinitely.
The DAL resolves and executes the contract.
The data runtime applies caching policy, resolves the named database contract, executes it with the complete parameter set, and prepares a DataSet containing the related tables and definitions expected by the screen.
Metadata completes the visual surface.
Tables bind to GridView and control families. Column definitions choose cell classes, lookup sources, display behavior, read-only rules, style, validation, and editor aliases. CtrlV zones, toolbar fields, commands, aggregates, and status become active against the loaded package.
Runtime state drives commands and relationships.
Selection changes update current-row context, master-detail children, cross-reference filters, aggregates, and validator variables. EvQueue coalesces noisy refreshes. WFValidator evaluates expressions and returns MC results that explain enabled, disabled, continue, confirm, or cancel behavior.
The user edits the relational entity directly.
A text field, lookup, date picker, hosted cell control, pivot row, or dynamic editor changes a DataRow. DataRowState and DataRowVersion retain the unit of work while grids and composites expose pending status through their validators.
The validated changeset returns and merges.
The save command resolves context again, selects the relevant changed rows, shapes a structured payload, obtains confirmation through MC when required, and invokes the DAL. SQL Server applies the authoritative contract; returned identifiers, values, statuses, and messages merge into the same live DataSet.
No central object has to understand the whole screen.
The host owns process and shared runtime concerns. The module owns business capability identity. The form owns window context. The composite owns screen structure. The controller owns relationships. The control owns its value and interaction. The validator owns rule evaluation. The DAL owns named contract execution. SQL Server owns the authoritative data contract.
Each participant sees only the contracts it needs. Context moves through contribution, state through DataRow and DataView, behavior through metadata, messages through MC, and dependencies downward through assemblies. The complete application emerges from those bounded responsibilities.
Variation is moved to the level where it belongs.
| Variation | Where it belongs | Why |
|---|---|---|
| Which module opens | Module registry | The shell remains independent of business assemblies. |
| Which dataset is requested | Named DAL contract | Controls express intent without embedding SQL or connection mechanics. |
| Which fields and cells appear | Entity and column configuration | Supported shape and editing variation does not require a new form. |
| Which controls compose a screen | Control tree and aliases | Stable compiled types can be rearranged and reused. |
| Which commands are available | Command definitions plus WFValidator | Action identity and rule-driven status remain consistent. |
| Which presentation edits an entity | EdtrFactory configuration | List, pivot, group, image, or modal behavior does not change the edit request. |
| Genuinely new behavior | New compiled component | Configuration remains a controlled variation mechanism, not an unbounded programming language. |
The same structure that enables reuse localizes failure.
An invalid alias fails at activation with control and definition context. A missing parameter remains visible in the resolution checklist. A recursive relationship stops at the invocation trace. An invalid expression appears in validator diagnostics. A disposed form cancels its pending EvQueue callback. A stale or oversized cache can be inspected through cache status. A persistence rejection returns through the named contract and message system.
Runtime composition does not remove failure; it changes where failure appears. The framework therefore includes contextual exceptions, trace events, dataset and table explorers, cache inspection, validator visibility, status areas, and unified messages as part of the platform architecture.
This observability is essential. Without it, configuration would merely move logic out of code and make the system harder to understand. With it, the runtime state becomes another inspectable engineering artifact.
The final principle is cumulative reuse.
A new supported entity field can often become visible through schema and configuration because the data runtime, typed extensions, grid hierarchy, cell family, metadata parser, validator, command system, and persistence path already understand the pattern. A new module can reuse the host, forms, views, editors, security context, caching, messages, and diagnostics.
That does not mean no new class is ever needed. When behavior is genuinely new, the framework receives a new reusable component at the correct layer. Once added, configuration can apply that capability across future modules. The architecture converts one engineering investment into repeated operational leverage.
The platform is not the sum of a large class count. It is the set of contracts that allow those classes to cooperate without every module rebuilding the same data, UI, validation, command, and persistence infrastructure.
Explore the components individually.
The searchable dictionary records why each major class exists, what it contributes, and where it participates in the architecture.