Angular + ASP.NET Core Architecture

Angular + ASP.NET Core Architecture — Quick Revision

1. How should an Angular + ASP.NET Core application be structured?

Keep Angular as the frontend and ASP.NET Core Web API as the backend. Angular handles UI; ASP.NET Core handles business logic, security, data access, and APIs.

Angular → Web API → Application → Domain/Infrastructure → SQL Server

2. Should Angular directly reference an ASP.NET Core project?

No. Angular is a TypeScript application and does not take a project reference to C# projects. It communicates with ASP.NET Core through HTTP/HTTPS APIs.

this.http.get('/api/products');

3. Should Angular communicate only through the Web API?

Yes, for backend operations. Angular should call the Web API, rather than directly accessing SQL Server, Infrastructure, or backend assemblies.

Angular → HTTP → ASP.NET Core Web API

4. How does Angular communicate with an ASP.NET Core Clean Architecture solution?

Angular calls the API layer using HttpClient. The API invokes the Application layer, which coordinates Domain rules and Infrastructure implementations.

Angular → API → Application → Domain / Infrastructure → Database

5. Where should DTOs be defined in an ASP.NET Core backend?

In Clean Architecture, API-facing/use-case DTOs are commonly placed in the Application layer, although API-specific request/response contracts can also live in the API layer.

Application/DTOs/Products/ProductDto.cs

6. Should Angular use the same C# DTO classes?

No. Angular cannot directly use C# DTO classes. Define corresponding TypeScript interfaces/types matching the JSON contract returned by the API.

export interface Product { id: number; name: string; }

7. How do TypeScript interfaces correspond to ASP.NET Core DTOs?

The TypeScript interface should match the JSON shape of the C# DTO—property names and compatible data types should correspond.

C# ProductDto → JSON → TypeScript Product

8. Where should business logic reside: Angular or ASP.NET Core?

Core business rules belong in ASP.NET Core, especially the Application/Domain layers. Angular should mainly contain UI/presentation logic and client-side state.

Business rules → Backend | UI logic → Angular

9. Where should validation reside: Angular or ASP.NET Core?

Use validation in both. Angular validation improves user experience, while backend validation is the authoritative validation for security and business correctness.

Angular validation = UX | Backend validation = required

10. Why is client-side validation not sufficient?

Client-side validation can be bypassed by calling the API directly using tools such as Postman or custom clients. Therefore, the server must always validate incoming requests independently.

Never trust client input.

11. Where should authorization rules reside?

Real authorization must be enforced in ASP.NET Core. Angular guards can control navigation and UX, but they are not a security boundary.

[Authorize(Roles = "Admin")]

12. How do Angular, Web API, Application, Domain, Infrastructure, and SQL Server fit together?

Angular calls the Web API; API invokes Application use cases; Domain contains core business rules; Infrastructure handles external concerns such as EF Core/SQL Server.

Angular → API → Application → Domain ← Infrastructure → SQL Server

13. How do you separate Public and Admin features in Angular?

Organize them into separate feature folders/routes, typically with separate layouts and lazy-loaded route trees. Protect Admin routes using authentication/authorization guards.

features/public/   features/admin/

14. Should Public and Admin use the same ASP.NET Core Web API?

They can use the same Web API when appropriate, with different endpoints and authorization policies/roles controlling access. Separate APIs are needed only when architectural/security requirements justify them.

Public Angular ─┐
                ├→ ASP.NET Core Web API
Admin Angular ──┘

15. How do you organize API services in a large Angular application?

Organize services by business feature/domain, such as articles, users, and categories, rather than putting every HTTP call into one huge service.

features/articles/services/article-api.ts
features/users/services/user-api.ts