EBS Analysis: Common web application architectures – .NET

Understanding .NET Web Application Architectures

Enterprises that rely on .NET for their web solutions confront a pivotal decision early in any project: the architectural pattern that will shape the application’s long‑term maintainability, scalability, and cost. While the simplest approach is a single‑project monolith, real‑world business requirements often demand separation of concerns, testability, and the ability to evolve individual components without disrupting the whole system. This article explores the most common .NET web application architectures, examines how they are realized in ASP.NET Core, and highlights the practical implications for enterprise IT. The goal is to provide a clear, consulting‑grade reference that helps decision‑makers and technical leaders evaluate trade‑offs and plan a roadmap that aligns with business objectives.

Executive Introduction: Why Architecture Choices Matter for Enterprises

Architecture is the blueprint that dictates how code is organized, how services interact, and how an application grows over time. A poorly chosen architecture can lead to “spaghetti code,” tight coupling, and a deployment pipeline that stalls every time a new feature is added. Conversely, a well‑designed architecture empowers teams to deliver faster, maintain higher quality, and scale efficiently, often with lower total cost of ownership.

Enterprise IT must balance several competing pressures: regulatory compliance, security posture, rapid feature delivery, and the need to leverage cloud economics. The architectural pattern selected directly influences each of these dimensions. A monolithic design may be fast to prototype but can become a bottleneck when scaling or when isolating security patches. A layered approach improves separation of concerns but may still suffer from compile‑time dependencies that hinder unit testing. Clean Architecture, or its variants (Hexagonal, Onion), offers the strongest guard against change but introduces additional complexity and tooling requirements.

This article distills the guidance found in Microsoft’s “Architect Modern Web Applications with ASP.NET Core and Azure” and expands it with enterprise‑focused considerations. It does not prescribe a single “best” pattern; instead, it outlines the characteristics, implementation details, and operational impact of each major style so that organizations can make informed, context‑driven choices. The analysis is grounded in real‑world scenarios—such as eCommerce, enterprise resource planning, and line‑of‑business portals—while respecting the original technical material’s emphasis on separation of concerns, dependency inversion, and testable designs.

Core Architectural Styles in .NET

Monolithic Single‑Project Model

The monolithic single‑project model is the default scaffolding for a new ASP.NET Core project created in Visual Studio or via the command line. All concerns—presentation (Controllers, Views), business logic (Services, Models), and data access (Repositories, DbContext)—reside in a single assembly. The file structure typically includes separate folders for MVC components (Models, Views, Controllers) and auxiliary folders for Data and Services. This arrangement relies on folder‑based separation rather than project‑based isolation.

Benefits of the monolithic approach are immediate: a single compilation, straightforward deployment (one DLL, one configuration file), and simple debugging. For internal line‑of‑business applications or small public sites, this simplicity can outweigh the need for more complex organization. However, as the solution grows, the number of files, dependencies, and cross‑references increases, often leading to “spaghetti code” where business logic is scattered across Models and Services without clear dependency boundaries.

Key characteristics:

• All code compiled into one assembly.
• Single deployment unit (e.g., Azure Web App, Docker container).
• Scalable by cloning the entire unit (scale‑out) or adding resources (scale‑up).
• Testing can be performed end‑to‑end but unit testing of business logic often requires real infrastructure (database, UI).

Layered (N‑Tier) Architecture

When an application exceeds a few hundred files, teams frequently transition to a multi‑project solution where each project corresponds to a logical layer. The classic three‑tier model consists of:

• UI Layer – Controllers, Views, and client‑facing services.
• Business Logic Layer (BLL) – Use cases, application services, and domain logic.
• Data Access Layer (DAL) – Repositories, DbContext, and infrastructure‑specific code.

The UI layer depends on the BLL, and the BLL depends on the DAL; compile‑time dependencies flow downward. This structure promotes reuse of low‑level services across the solution and provides a clear line of responsibility for each project.

Layered architecture yields tangible benefits:

• Encapsulation – each layer can be replaced or mocked independently.
• Standardized data access – a single repository implementation can be shared.
• Facilitates testing – the BLL can be unit‑tested with a fake DAL.

However, the traditional layered approach suffers from a compile‑time dependency on infrastructure. The BLL must reference the DAL, making it harder to test without a real database and preventing the BLL from being truly independent of persistence technology.

Clean Architecture / Onion Architecture

Clean Architecture (also known as Onion Architecture) inverts the dependency flow of the layered model. The core—often called Application Core or Domain Core—contains business entities, use‑case services, and interfaces that represent operations (e.g., IProductRepository). The outer layers—Infrastructure, UI, and cross‑cutting concerns—depend on the core through these abstractions. Dependencies point inward; the core has zero dependencies on outer layers.

This pattern aligns closely with the Dependency Inversion Principle and Domain‑Driven Design. It enables:

• Easy swapping of implementations (e.g., SQL Server vs. Azure Cosmos DB) without touching business logic.
• Isolated unit testing of the core—no need for a real data store or UI.
• Clear separation of concerns; each concentric circle has a well‑defined purpose.

Microsoft’s eShopOnWeb reference demonstrates Clean Architecture by splitting the solution into Application, Infrastructure, and Web projects. The Web project references both Application and Infrastructure, while Infrastructure references Application to satisfy its service implementations. Dependency injection (DI) is used to wire concrete services into the interfaces defined in the core.

How These Patterns Are Implemented in ASP.NET Core

All three styles can be realized within ASP.NET Core, but the project structure and startup configuration differ. In a single‑project monolith, the Program.cs (or Startup.cs in older templates) lives in the same project as controllers and services. The DI container is configured there, and the DbContext is registered alongside repository implementations.

In a layered solution, each project has its own .csproj. The UI project’s Program.cs typically references the BLL and DAL projects. DI registrations in the UI project may delegate to extension methods defined in the BLL or DAL, preserving a single composition root. This keeps the UI’s Program.cs clean while still wiring all dependencies.

Clean Architecture adds another dimension: the Application Core project does not reference any infrastructure projects. Instead, it defines interfaces such as IProductRepository. The Infrastructure project implements these interfaces, registers them in the DI container, and may also contain EF Core DbContext classes. The Web project (UI) references both Application and Infrastructure, but never directly instantiates concrete repository classes—only the interface. This setup is often expressed in Program.cs using methods like builder.Services.AddInfrastructure() and builder.Services.AddApplication().

Implementation Considerations

Project Organization and Dependencies

Clear project boundaries reduce cognitive load. When moving from a single project to multiple projects, teams should ask:

• What concerns are tightly coupled? (e.g., data access patterns)
• Which components need independent versioning? (e.g., UI theme vs. business logic)
• What is the expected test granularity? (unit test the domain, integration test the DAL)

Common folder layouts for each style are shown in the original source but should be adapted to match organizational standards. For example, a layered solution might adopt the classic MVC folders inside the UI project, while the BLL project contains a “Services” folder and the DAL project contains a “Repositories” folder.

Dependency Injection and Composition Root

ASP.NET Core’s built‑in DI container is pivotal for Clean Architecture. The composition root is the place where concrete implementations are registered against abstractions. Best practices include:

• Keep registration logic in extension methods or separate startup classes to avoid cluttering Program.cs.
• Use interfaces defined in the Application Core as the key for registration.
• Avoid direct new T() in service classes; always rely on DI.

Security‑wise, DI can be leveraged to enforce scoped lifetimes for database contexts, ensuring that connections are not inadvertently shared across request boundaries. This also aids in operational hygiene when swapping connection strings per environment.

Data Access Patterns (Repository, Unit of Work)

EF Core is the most common data access technology in .NET. The Repository pattern abstracts the EF DbContext behind an interface, enabling the Infrastructure project to hide provider‑specific details. A Unit of Work pattern can group multiple repository operations into a single transaction, which is valuable for data‑intensive business processes.

When implementing data access, consider:

• Configuration management – store connection strings in Azure App Configuration or Key Vault rather than source code.
• Performance – use asynchronous methods and appropriate query shaping.
• Security – limit permissions on the database to the minimal required for each repository.

Testing Strategies (Unit vs Integration)

Clean Architecture makes unit testing the core straightforward because the core has no external dependencies. Test projects can target the Application Core assembly alone, mocking interfaces like IProductRepository. Integration tests, on the other hand, target the Infrastructure project, spinning up a real database (or using an in‑memory provider) to verify end‑to‑end behavior.

Operational considerations for testing include:

• Isolation – use disposable databases (e.g., SQLite in‑memory) for unit tests; use test containers (Docker) for integration tests.
• Seeding – maintain a reliable dataset that can be reset across test runs.
• Security – ensure test data does not contain production credentials.

Security and Governance Implications

Architecture influences security posture in several ways. The separation of concerns inherent in layered and clean models supports the principle of least privilege:

• UI layer can be restricted to specific HTTP endpoints and authentication schemes without exposing business logic.
• Infrastructure components can be granted only the permissions needed for database access, file system operations, or external API calls.

Governance can be simplified by enforcing consistent coding standards per project. For example, a policy can require that no UI project directly references a DAL assembly; this prevents accidental leakage of infrastructure details into the presentation tier.

Dependency injection also improves security because it reduces the risk of hard‑coded secrets in service classes. Configuration can be sourced from Azure Key Vault, with fallback values in appsettings files for dev environments. Additionally, ASP.NET Core’s built‑in features such as endpoint routing, CORS, and antiforgery tokens can be applied per layer to further harden the application.

Operational Implications and Cloud Deployment

Scaling Strategies (Scale‑Up vs Scale‑Out)

Monolithic applications are traditionally scaled out by adding identical instances behind a load balancer (scale‑out) or by increasing resources on a single VM (scale‑up). Azure App Service Plans allow developers to configure the number of instances directly in the dashboard. For clean‑architectured solutions, scaling is equally straightforward, but the separation of concerns can enable more targeted scaling:

• UI instances can be duplicated to handle request spikes.
• Business logic services (if exposed as separate micro‑services) can be scaled independently.

Scaling decisions should consider the “choke point” pattern. In an eCommerce scenario, the product catalog component often sees the highest read traffic, while order processing sees lower volume. A monolithic deployment would scale the entire application, potentially over‑provisioning under‑utilized services.

Containerization and Docker

Containers abstract the underlying OS and provide immutable deployment units. Docker images for .NET applications are typically based on the official mcr.microsoft.com/dotnet/aspnet image, layered with application code via multi‑stage builds. The benefits include:

• Consistent environments from development to production.
• Faster rollouts—images can be started within seconds.
• Easier orchestration with Kubernetes or Azure Container Instances.

When using containers, the container principle (“a container does one thing, and does it in one process”) may conflict with monolithic designs that pack UI, BLL, and DAL into a single process. However, many enterprises start with a monolithic container and later decompose it when specific components become scaling bottlenecks.

Azure App Service and Virtual Machine Scale Sets

Azure App Service offers a fully managed hosting environment that automatically handles OS patching, load balancing, and scaling. It supports both static ports and Docker containers via the “Docker” option in App Service Plan configuration. For monolithic .NET apps, App Service provides an easy entry point with built‑in diagnostics, SSL termination, and automatic scaling.

For more control, Azure Virtual Machine Scale Sets allow autoscaling of VMs running Docker hosts. Each VM can host multiple container instances, and the scale set automatically adds or removes VMs based on custom metrics (CPU, memory, queue length). This model is suitable for large‑scale deployments where fine‑grained control over the underlying infrastructure is required.

Common Pitfalls and Anti‑Patterns

Even well‑intentioned teams can fall into traps when adopting any architecture pattern:

• Spaghetti Dependencies. In layered designs, the UI may inadvertently reference DAL types, breaking encapsulation and making refactoring risky.
• Over‑Engineering. Introducing Clean Architecture for a small internal tool can add excessive complexity and tooling overhead.
• Testing Infrastructure Coupling. Relying on a real database for unit tests defeats the purpose of layered separation and slows CI pipelines.
• Misaligned Scaling. Scaling a monolith when only one component needs growth leads to unnecessary cost and resource waste.
• Docker Image Bloat. Including debugging symbols and source code in the final image can increase deployment time and attack surface.

Mitigation strategies include regular architecture reviews, automated dependency analysis tools (e.g., NDepend, StyleCop), and enforcing automated testing gates in CI/CD pipelines.

Why This Matters to Enterprise IT

Enterprise IT is under constant pressure to deliver reliable, secure, and performant applications while controlling costs. The architecture chosen for a .NET web application directly influences:

• Time to Market. Clean Architecture can accelerate feature delivery by allowing independent evolution of UI, business logic, and data access.
• Risk Management. Separation of concerns improves isolation, making security patches and compliance audits easier.
• Operational Efficiency. Containerized monoliths simplify deployment pipelines, while microservices enable fine‑grained scaling.
• Team Productivity. Well‑defined project boundaries enable cross‑functional teams to own specific layers, aligning with modern DevOps practices.

By understanding the trade‑offs among monolithic, layered, and clean architectures, IT leaders can make informed decisions that balance immediate development speed with long‑term maintainability. This insight also guides investment in tooling (e.g., dependency injection containers, CI/CD orchestrators) and training for development teams.

EBS Consulting Perspective

From a consulting standpoint, the most valuable outcome of an architecture assessment is a pragmatic roadmap that aligns technical design with business goals. EBS typically begins by mapping existing codebases against the three core patterns described above, identifying:

• Areas where current dependencies violate encapsulation (e.g., UI referencing DAL).
• Testing bottlenecks that increase cycle time.
• Scaling histories that indicate uneven resource utilization.

Based on this diagnosis, we recommend a graduated approach: preserve the existing monolithic structure for rapid prototyping, introduce explicit layered projects to improve separation, and progressively adopt Clean Architecture principles as complexity grows. This incremental methodology reduces risk, allows teams to gain experience with each pattern, and avoids the “big bang” rewrite that many enterprises have experienced as costly failures.

EBS also emphasizes governance by embedding architectural guidelines into code repositories (e.g., .editorconfig, project templates). Automated checks in pull requests can enforce that UI projects never directly reference Infrastructure assemblies, preserving the inversion of control that Clean Architecture demands.

Practical Next Steps

Organizations seeking to improve their .NET web application architecture can follow this step‑by‑step plan:

1. Audit Current Structure. Use tools like Visual Studio’s Dependency Graph or third‑party analyzers to visualize project references and identify tight couplings.
2. Define Layer Boundaries. Draft a simple diagram that demarcates UI, BLL, DAL, and, if applicable, a separate Infrastructure layer. Document the public interfaces each layer exposes.
3. Introduce a Core Project (Optional). If the solution is already multi‑project, consider extracting a shared “Domain” assembly that contains only business entities and interfaces. This is the first step toward Clean Architecture.
4. Refactor Dependency Flow. Remove direct UI references to DAL types. Replace them with interfaces defined in the BLL. Register concrete implementations in the Infrastructure project using DI.
5. Implement Unit Tests for Core Logic. Target the Domain/Core assembly in a test project, mocking infrastructure interfaces. This provides immediate confidence that business rules are independent.
6. Establish CI/CD Pipelines. Configure automated builds that run unit tests, integration tests, and container image generation. Use Azure DevOps, GitHub Actions, or similar.
7. Containerize the Application. Create a multi‑stage Dockerfile that copies the application code, restores dependencies, builds, and publishes to a slim runtime image. Test locally with Docker Compose to simulate production topology.
8. Deploy to Azure App Service (or VM Scale Set). Publish the container image to Azure Container Registry, then configure App Service with the Docker option. Enable auto‑scale based on CPU or custom metrics.
9. Monitor and Optimize. Enable Application Insights for telemetry, set up alerts for error rates, and review scaling metrics to fine‑tune instance counts.
10. Iterate. As the application evolves, re‑evaluate the architecture. If certain features repeatedly require scaling, consider extracting them as dedicated services following the same Clean Architecture principles.

Conclusion and Consulting Next Steps

The choice between a monolithic, layered, or clean architecture is rarely binary. Most .NET enterprises start with a simple monolithic deployment that meets immediate needs, then mature their approach as the application expands, compliance requirements tighten, and scaling demands become more nuanced. Understanding the strengths and limitations of each pattern equips technical leaders with the knowledge to guide incremental refactoring toward a more maintainable, testable, and scalable solution.

EBS offers architecture assessments, project re‑engineering, and training programs tailored to help organizations transition safely from monolithic designs to more modular, cloud‑ready architectures. By combining deep technical expertise with a focus on business outcomes, we partner with enterprises to build .NET web applications that are resilient, secure, and positioned for future growth.

If your organization is ready to evaluate its current .NET web application architecture or explore a roadmap toward Clean Architecture and containerized deployments, contact us to schedule a discovery workshop. Our consultants will work with your teams to define clear objectives, select the appropriate patterns, and deliver a pragmatic implementation plan that aligns with your strategic priorities.

EBS Consulting Advice

If your organization is evaluating Common web application architectures – .NET, do not treat the technology decision in isolation. Start with the business outcome, current architecture, security and identity controls, operational constraints, migration dependencies and governance requirements. A practical assessment should identify the current-state gaps, prioritize the risks and define an implementation roadmap with measurable outcomes.

EBS can help assess the environment, develop the architecture and modernization roadmap, and translate the technical options into an actionable business plan. Relevant EBS services: Microsoft Azure consulting Escape Cloud Microsoft Consulting.

Have a technology challenge? Email info@escapebusinesssolutions.com to describe your situation. We welcome questions, consulting discussions and requests for a proposal.