Production Architecture Deep Dive

Refactor TicketOps by giving the interface and business operations separate responsibilities. The goal is a structure where another developer can find a rule, change its implementation, and verify the result without searching through button handlers.

The crowded handler mixes database queries, validation, workflow decisions, and screen updates. Those responsibilities change for different reasons, so keeping them together makes even a small correction harder to isolate and review.

Create folders that name the intended responsibilities, then use those names to decide where code belongs. The benefit comes from consistent boundaries, not from moving the same tightly coupled handler into a differently named file.

Define the ticket service interface around the operations the screen actually needs. The form can then depend on a stable contract while tests or later storage implementations provide different ways to fulfill it.

Implement a fake ticket service first and move the workflow decisions into it. This lets you verify the screen's interaction with the contract before introducing real data access and its additional failure cases.

The handler now delegates the operation, displays its result, and handles failure. Read it as a description of the user's action; the business rules should be understandable in the service rather than hidden among control updates.

Run locally and check both the populated grid and the refreshed status. The two results should agree: the service supplied the data, and the interface now tells the user that the refresh completed.

Give the user an understandable failure message while retaining the real exception in the log. This separates the explanation needed to continue working from the diagnostic detail developers need to investigate the cause.

Decide how the Wisej.NET application starts and where its state belongs before adding more workflows. Configuration and lifetime choices determine whether each user's screen sees the correct data as sessions and tabs change.

A session represents a running interaction, not simply a person's identity. Refreshes, reconnects, and multiple tabs mean one user can have several contexts, so selected records should not automatically be stored as user-wide state.

For each value, distinguish application-wide, session, user, and tab ownership. Ask who should observe a change and when it should disappear; those answers guide the lifetime more reliably than the convenience of a global field.

Review Default.json as part of deployment, including theme, timeout, client session limits, validation, and culture. These settings influence runtime behavior, so they need deliberate values and review alongside the application code.

Ordinary static fields are shared across sessions even though Wisej.NET provides session-aware access through Application. Do not infer that your own static selected-ticket field gains the same isolation; it can expose another session's value.

Put session-owned values in a session context or the session storage provided by Wisej.NET. Each session then has its own instance, making the intended isolation visible in the design rather than relying on naming conventions.

Define the session context with a session identifier, current user, and selected ticket. Grouping these related values makes it clear which context a form or service is using when it handles an operation.

Pass the context into forms and services that need it. The ticket-selection handler writes to that context, so its dependency is visible and the selection belongs to the current session instead of a shared global variable.

Select a ticket in the running application and read the session-specific status. Confirm that the displayed selection comes from the current context; this is the visible result of the ownership decision made earlier.

Keep applying the same discipline throughout TicketOps: designable screens, understandable names, service boundaries, and visible failures. Clear state ownership complements those practices by making behavior easier to review across multiple sessions.

Adapt the Ticket Workspace to desktop, tablet, and phone by preserving the task at each size. The layout should change how information is arranged without making users lose the record or action they are working on.

Start with what operators need to compare, read, and act on together. Overlapping panels are not merely untidy; they can hide the message or record that gives an action its meaning.

Choose containers according to their job: edge attachment, tabular alignment, flowing items, or flexible distribution. Matching the layout mechanism to the intended relationship is more reliable than manually positioning every control for each width.

Package repeated interface sections into UserControls that remain usable in the designer. A shared search bar gives multiple screens one maintainable layout and behavior, while the workspace composes those parts into a larger task.

Use ClientProfiles.json to describe the profiles that drive server-side property changes. A profile is a deliberate adaptation rule, so keep its effect understandable rather than scattering width checks throughout unrelated event handlers.

Apply the active profile in one handler: hide navigation, move activity into a tab, and expose a back action where needed. Centralizing these coordinated changes makes each layout mode easier to understand and verify.

Test the same workflow at each width. Desktop shows the full context, tablet moves activity into a tab, and phone focuses on one task; check that users can still reach the information and actions they need.

Deliver the workspace, profiles, profile notes, and reusable search bar together. Explain what each profile changes and why, so the next developer can preserve the workflow when adding another panel or screen.

Connect the TicketOps list and editor so users can inspect, change, and save the same business record coherently. Binding reduces manual synchronization, but the workflow must still define selection, unsaved changes, and save outcomes.

A binding connects a model property to a control property, while BindingSource coordinates the current item. Use that shared source for list and details so a selection change consistently updates the editor's context.

Property-change notifications tell bound controls when a work order value changes. A binding-aware list reports collection changes separately; together these notifications prevent the grid from depending on manual refreshes after every edit or addition.

Connect the grid to a BindingSource, and connect that source to the list. Choose the columns deliberately. Keep display formatting in the user interface, separate from the data and business rules.

Use search and status filtering to narrow the list, then let its selected row determine the detail record. Keeping that relationship explicit helps users understand exactly which work order their next edit will affect.

Track whether the editor has unsaved changes. Cancel should restore the previous values, while Save attempts to commit them; if it fails, report that failure instead of letting the bound display imply the data was persisted.

Provide the model, binding setup, formatting handlers, editor, and commit or cancel notes. The handoff should explain how a selected record moves from display to editing and then to either a saved or restored state.

Make the work order editor explain invalid input before it attempts an unsafe save. The validation pipeline connects field feedback to business rules and persistence, so the user knows what must change and whether anything was saved.

Distinguish interface checks, business validity, persistence constraints, and authorization. Each protects a different boundary; disabling Save can guide users, but the service must still reject a request that violates its rules or permissions.

Place each error near the field that needs attention and collect the issues in a summary. Use language that explains the correction, so users can locate the problem without understanding the underlying exception or database rule.

Collect and validate the input before creating the command. Check the business rules and authorization before saving. Only after a successful save should the application refresh the screen and record the outcome.

Stop early when validation fails, before persistence starts. If the storage operation itself fails, keep the real diagnostic detail in the log and explain the unsuccessful save plainly instead of presenting an internal error to the user.

Apply the pipeline to required fields, due dates, cost limits, status transitions, and role restrictions. These cases span different layers, which helps verify that the editor does more than check whether a text box is empty.

Trigger a failed save and inspect the editor afterward. The user's edits should remain available, the message should explain the problem, and internal details should appear only in the log so recovery does not require retyping the work.

Good validation protects data while helping people finish their work. Preserve context, explain corrections, and distinguish a rejected input from a failed save so the next action is clear.

Use an approval dialog to make the user's decision explicit before changing business state. The screen gathers intent, returns a structured result, and gives the service a clear point at which execution may begin.

Opening a modal should mark a real decision boundary in the workflow. Users need to understand what they are confirming and what cancellation means before the application performs the consequential action.

Keep the dialog focused on approving or rejecting, with comments and explicit confirmation or cancellation. A single decision makes the result easier to validate and prevents unrelated changes from becoming hidden side effects.

Await the dialog and read its typed approval result instead of inspecting unrelated control properties afterward. The result carries the decision as one contract, keeping the caller independent of how the dialog arranges its fields.

Only a confirmed result should trigger the service transaction. Keeping execution outside the dialog means the same approval rules remain in the business operation rather than depending on a particular window being open.

Require comments when the user rejects, because the reason is part of that decision. Test both Cancel and the close button: neither should issue the service command or change the business record.

Deliver the dialog, typed result, service command, workflow diagram, and test cases. Show confirmation, rejection with comments, and cancellation so the handoff describes both the action and the paths that deliberately make no change.

Import comma-separated values in the background while keeping the screen responsive. Users should be able to see progress, request cancellation, and understand the final report without wondering whether the application has stopped responding.

A long import inside the click handler keeps the session occupied with that work. Moving the operation out of the immediate interaction allows the screen to remain useful while the import processes its rows.

Start the background operation with Application.StartTask, then return to the correct session context before accessing controls. RunInContext establishes that boundary, so work running elsewhere does not update controls as though it already belonged to the interface context.

Publish progress at meaningful milestones and use Application.Update to deliver those changes to the browser. Record invalid rows individually so one bad record can appear in the report without unnecessarily ending the entire import.

Let Cancel request cancellation through the cancellation token while the interface remains available. The worker must observe that request at safe points; pressing the button should lead to a controlled result, not an unexplained interruption.

Run another import through completion and compare success, cancellation, and error outcomes. Each path should leave controls in a coherent state with a useful report, so the user can understand the result and begin another operation.

Treat launch, progress, cancellation, and reporting as one user workflow. The background implementation succeeds when the user remains informed and in control throughout the operation, not merely when the import eventually finishes.

Let screens declare the services they need through dependency injection. This separates their work from construction decisions, allowing the same interface to use a demonstration implementation now and a production implementation later.

Define interfaces for the capabilities the screen consumes, such as tickets, users, permissions, notifications, and audit. These contracts should describe useful operations rather than exposing the internal classes or storage choices behind each service.

Register the fake services in Application.Services and choose their lifetimes deliberately. The injection attribute then supplies the page's dependencies, letting you exercise the service contract before connecting real infrastructure.

Move the screen's coordinating decisions into a presenter, leaving controls responsible for interaction and display. Database queries, permission decisions, and cross-screen rules then become easier to inspect without navigating the visual control tree.

Compare shared, session, thread, and transient lifetimes against what the service stores. Anything user-specific needs the appropriate session scope; a convenient shared registration must not turn one user's context into another user's dependency.

Replace the fake registration with a production implementation that fulfills the same interface. The screen should continue calling the same operations, demonstrating that infrastructure changes do not require rewriting the interaction logic.

Dependencies are easier to reason about when they are declared, replaceable, and scoped correctly. A reviewer should be able to see what a screen needs and test those interactions without constructing the entire production environment.

Add a keyboard shortcut and clipboard helper as focused browser enhancements. The examples show how local interaction can become faster while the server still controls the link content and records the operation.

Use JavaScript for browser-side behavior such as shortcuts, widget interactions, and browser programming interfaces. Give it a specific enhancement to own while keeping business decisions in the server-side application where they remain enforceable.

Keep the script in a named, maintainable source and attach it only after the widget exists. An embedded resource or JavaScriptSource makes the behavior easier to locate, while correct lifecycle timing gives it a valid target.

Handle Control K in the browser to focus global search immediately. Since this action only changes focus, it does not need a server round trip before the user can begin entering a query.

Build the safe link on the server, then invoke the clipboard behavior through Application.Eval and record the action. The browser performs the local clipboard interaction while the application retains control of what is being shared.

Document what data goes to JavaScript, what result comes back, and which decisions remain on the server. That boundary makes the enhancement easier to review and prevents a browser convenience from quietly acquiring business authority.

Keep each script small enough that its purpose and boundary are obvious. Focused browser behavior is easier to maintain when it complements the Wisej.NET workflow and does not become an alternate home for business rules.

Modernize the dashboard through shared visual rules and culture-aware content. A consistent theme, reusable status display, and localized formatting help users recognize the same workflow even when its language and available space change.

Put broad appearance choices into the theme before adding control-specific exceptions. Central rules let a visual adjustment reach the whole application, while scattered local overrides make the same change harder to apply consistently.

Create one status-chip UserControl to own its text, color, and spacing. Reusing that component prevents screens from inventing different visual meanings for the same status and gives future adjustments one place to live.

Store user-facing labels in resources and format dates and money through the selected culture. Translation and formatting solve different problems, so changing the language must also produce values users can interpret correctly.

Switch culture in the actual dashboard and inspect both text fit and formatted values. Longer German labels can expose layout assumptions, while changed dates and currency reveal whether formatting follows the selected culture rather than hard-coded text.

Review spacing, hierarchy, contrast, icons, status messages, and theme exceptions together. These checks connect visual consistency to practical reading and action, helping identify an attractive screen that still obscures important information.

A polished dashboard keeps its meaning across screens and cultures. Shared components and resources make consistency maintainable, while testing real translated layouts confirms that the design still supports the user's task.

Enforce sensitive actions in the service that performs them. This module uses the interface to guide legitimate users while proving that the server rejects unauthorized requests even when the screen's controls are manipulated.

Establish the session's identity before allowing sensitive workflows to begin. Authentication provides the trusted answer to who is acting, which the later permission checks use when deciding whether that person may perform an operation.

Authorize at the execution boundary and audit both success and denial. A record of rejected attempts matters alongside completed actions, because it explains why a request made no change and supports investigation of misuse.

Force the button into an enabled state and try the restricted action. The service must still deny it, demonstrating that a helpful interface setting is not the mechanism protecting the underlying operation.

Encode user-provided text before placing it on surfaces that can interpret markup. Review every AllowHtml path deliberately so content intended as data cannot unexpectedly become executable or active page structure.

Audit important actions and inspect the surrounding session, cookie, upload, logging, and Content Security Policy settings. These checks complement service permissions by reviewing how identity, incoming content, and diagnostic information travel through the application.

The server must be able to reject an unsafe request regardless of how it reached the application. Clear identity, service-level permission checks, safe output, and meaningful audit records work together to enforce that boundary.

Prepare TicketOps for operation after publication. The capstone includes hosting decisions, health evidence, diagnostics, and recovery instructions so someone besides the developer can verify and support the running application.

Choose the hosting target by checking its effect on configuration, logs, scaling, identity, and WebSocket connections. Those requirements shape the support plan, so record them before treating publication as a completed deployment.

Expose safe health information through HealthCheck.json for monitors and load balancers. The response should help determine whether the instance is usable without revealing credentials or other configuration details that operational callers do not need.

Put environment information, logging status, and checks on a role-protected diagnostics page. This gives authorized support staff a consistent starting point while limiting the information shown to what is useful for operating the application.

The server holds each user's session state. Configure sticky sessions so the load balancer keeps that user on the correct instance. The deployment must also allow the application's WebSocket connection through.

Package the checklist, diagnostics, release notes, rollback notes, and demonstration script together. The package should explain what changed, how to verify it, and how to recover, making the release reviewable by another person.

The capstone is ready to hand over when its operation is as understandable as its screens. Keep the release evidence with the application so support and future changes start from a shared, documented baseline.