Introduction

Many companies and organizations face the ongoing challenge of receiving, storing, and processing applications, proposals, and other types of submissions from external users, customers, or business partners. Building a dedicated backend for every client platform or business requirement can lead to duplicated code, increased maintenance costs, and fragmented data flows.

A centralized multi-tier architecture can address these challenges by separating the presentation layer from the underlying business and data access layers. This approach allows multiple client applications to communicate with the same backend services while sharing common data structures, validation rules, and processing logic.

This article presents a practical implementation of Submission Manager , a generic multi-tier .NET solution designed to simplify the processing and management of submissions. The solution uses a centralized ASP.NET Web API backend that can serve different client applications, including a modern Blazor web frontend and a traditional Windows Forms desktop application.

The article also demonstrates how the generic architecture can be adapted to different business scenarios with minimal changes to the existing application infrastructure. In particular, the user interface can be customized through localization, labels, and configuration while the core backend services and data-processing pipeline remain reusable.

As a practical example, the solution is configured for job application processing . The example demonstrates how job applications submitted through the Blazor web application are received by the Web API, stored in the database, and subsequently accessed and managed through the Windows Forms administrative application.

Prerequisites and Source Code

Before diving into the code implementation and multi-tier architecture details, you can access the complete open-source project repository:

Requirements

To build and run the solution, you should have the following:

Solution Architecture

To achieve a clear separation of concerns and maintain a modular structure, the Submission Manager solution is organized as a multi-tier application. This architecture allows multiple client applications to communicate with the same centralized backend while sharing common data structures and processing rules.

The solution is divided into the following main projects:

SubmissionManager screen shot 6

SubmissionManager.Shared (Shared Library): Contains common data models, Data Transfer Objects (DTOs), attributes, extensions, helper classes, resources, and view models. This library is referenced by the other application layers to provide consistent data structures and shared functionality. Localization resources and UI-related definitions can also be maintained here, allowing client applications to adapt labels and terminology to a specific business domain without changing the underlying data contracts.

SubmissionManager screenshot

SubmissionManager.Data (Data Access Layer): Responsible for database access, Entity Framework Core configuration, the database context, entities, and persistence-related operations. The layer uses Entity Framework Core with SQL Server to provide centralized and persistent storage for submitted data.

SubmissionManager screen shot 2

SubmissionManager.API (Backend Service Layer): Implements the centralized ASP.NET Core Web API . It exposes RESTful endpoints used by the client applications to submit, retrieve, update, and manage data. By keeping the API independent of client-specific presentation and localization, the same backend services can be consumed by different types of applications.

SubmissionManager screen shot 3

SubmissionManager.Web (Blazor Web Client): Provides the web-based user interface built with Blazor components, layouts, and pages. Users can access the application through a standard web browser to submit and manage information. Adapting the interface to a different business scenario primarily involves changes to the presentation layer, localization resources, form labels, and related configuration rather than changes to the shared backend infrastructure.

SubmissionManager screen shot 4

SubmissionManager.Admin (Windows Forms Desktop Client): Provides a traditional Windows Forms administrative interface. The application communicates with the same centralized Web API using HttpClient , allowing administrators to retrieve and manage submitted records through a dedicated desktop environment.

SubmissionManager screen shot 5

This modular architecture ensures that submissions received through the Blazor web application and records managed through the Windows Forms client ultimately use the same centralized API and persistence layer. This avoids duplicating backend processing logic for each client application and provides a common foundation for future client implementations.

Adapting the System to a Job Application Scenario

To demonstrate how the generic platform can be adapted to a concrete business requirement, the Submission Manager solution is configured as a job application system. The underlying architecture, shared data contracts, API services, and persistence layer remain unchanged, while the presentation layer and localization resources are adapted to the recruitment scenario.

This approach allows the same application infrastructure to be reused for different types of submission workflows without requiring changes to the core backend architecture.

Screenshot web

Localization and UI Adaptation

Adapting the platform for recruitment primarily involves configuring the localization resources and presentation layer to use terminology appropriate for job applications.

Common fields and data contracts remain unchanged, while domain-specific labels and descriptions can be adjusted to represent concepts such as Candidate , Address , Curriculum Vitae , Cover Letter , and Notes . The same localization mechanism also provides multilingual language selection and localized privacy and data-protection notices.

This separation between the underlying data model and the presentation terminology makes it possible to reuse the same application infrastructure for other submission scenarios with relatively limited changes to the client-side configuration and resources.

Job application admin screenshot 24 08 2026

Database and Backend Deployment

For deployment, the persistence layer is configured to use the target SQL Server instance. Entity Framework Core migrations can then be applied to create or update the required database schema.

The shared data model is designed around a generic submission-processing workflow, allowing the same persistence and processing infrastructure to support different submission scenarios without requiring application-specific database redesign for every new client use case.

API Publication

The SubmissionManager.API project can be published to an IIS web server or another suitable hosting environment. The production environment is configured with the appropriate SQL Server connection string and other deployment-specific settings.

The Web API serves as the central communication layer between the client applications and the persistence tier. Both the Blazor web application and the Windows Forms administrative application communicate with this API rather than accessing the database directly.

Client Distribution and Hosting

Client deployment is divided between the web-based submission portal and the desktop administrative application.

The SubmissionManager.Web application is published to a web server, allowing applicants to access the submission form through a standard web browser. Depending on the configured scenario, users can select their preferred language, complete the required information, review the applicable privacy notice, and submit their application.

The SubmissionManager.Admin application is distributed to authorized administrative users. It communicates with the same centralized Web API through HttpClient , providing access to submitted records without requiring direct database connectivity on the client machines.

Administrative Operations

The Windows Forms application provides the administrative interface for processing submitted applications. Administrators can retrieve candidate information, review submitted data, track application-related information, record contact dates, and maintain internal notes.

Because these operations are performed through the centralized Web API, the desktop client does not need to implement its own database access or duplicate the business and persistence logic already provided by the backend.

This demonstrates one of the main benefits of the architecture: different client technologies can participate in the same workflow while relying on a common service and data-access infrastructure.

Conclusion

Building a reusable multi-tier system for receiving, storing, and processing external submissions does not require creating a separate backend implementation for every client application or business scenario. By combining a centralized ASP.NET Core Web API , Entity Framework Core persistence layer, and modular Blazor and Windows Forms clients, the Submission Manager architecture provides a common foundation for different submission workflows.

The job application scenario demonstrates how the generic platform can be adapted to a concrete business domain primarily through presentation, localization, and configuration changes. The same architectural foundation can subsequently be reused for other scenarios, such as customer inquiries, service requests, proposals, registrations, or internal submission workflows.

The key advantage is therefore not simply the ability to support multiple client technologies, but the separation of responsibilities between the clients, API, shared contracts, and persistence layer. This reduces duplication, simplifies maintenance, and makes it easier to extend the system with additional clients or business scenarios while preserving the existing backend infrastructure.