Skip to main content

20 - Let the AI explain

First prompt​

explain how user login flow is handled in this codebase. where is login ui coming from? how are users authenticated. show code snippets from this codebase. where are users stored? how are users and database connected to each other. provide simple explanations.

Click the enhance prompt with additional context...

Improved Prompt​

Provide a comprehensive, end-to-end explanation of the user login flow in this codebase, covering every layer from the frontend to the backend to the database. Structure your explanation as a clear walkthrough that follows the journey of a user logging in, and include relevant code snippets directly from this codebase to support each point.

Specifically address the following in order:

First, explain where the login UI originates. Identify the exact files, components, or templates that render the login page or form. Show the relevant frontend code and describe how the login form captures and submits user credentials.

Second, trace what happens when the user submits their credentials. Walk through the route, controller, middleware, or API endpoint that receives the login request. Show the code that handles this request.

Third, explain the authentication mechanism in detail. How are user credentials verified? Is there password hashing, token generation such as JWT or session cookies, or integration with an external authentication provider like OAuth? Show the specific code responsible for credential validation and session or token creation.

Fourth, explain where and how users are stored. Identify the database system being used, show the user model or schema definition, and describe the fields stored for each user. Include any migration files, ORM models, or schema definitions present in the codebase.

Fifth, explain how the application connects to the database. Show the database configuration, connection setup, and how the user model interfaces with the database layer. Describe any ORM or query builder being used and how it maps user data between the application and the database.

Finally, describe what happens after successful authentication. How is the authenticated state maintained across requests? How does the application handle failed login attempts, and is there any redirect logic, error messaging, or rate limiting in place?

Use simple, beginner-friendly language throughout, as if explaining to someone who is reading this codebase for the first time. Avoid vague generalizations and ground every explanation in actual code from this repository.

AI Response​

Complete User Login Flow — End-to-End Walkthrough

This codebase is an ASP.NET Core application that supports two distinct login flows: a traditional server-side cookie-based login (via ASP.NET Identity's scaffolded Razor Pages) and a REST API JWT-based login (for API consumers like SPAs or mobile apps). Both flows share the same user store, password hashing, and database.

1. Where the Login UI Originates​

The Layout and Navigation Bar​

Every page in the app inherits from WebApp/Views/Shared/_Layout.cshtml:49. On line 49, it renders a partial view for login/logout controls:

<partial name="_LoginPartial"/>

The Login Partial View​

WebApp/Views/Shared/_LoginPartial.cshtml:1 injects ASP.NET Identity's SignInManager and UserManager, then conditionally renders either a "Hello, user!" + Logout button (if signed in) or Register + Login links (if not):

@inject SignInManager<AppUser> SignInManager
@inject UserManager<AppUser> UserManager

@if (SignInManager.IsSignedIn(User))
{
    // Shows "Hello <username>!" and a Logout form
}
else
{
    <a asp-area="Identity" asp-page="/Account/Register">Register</a>
    <a asp-area="Identity" asp-page="/Account/Login">Login</a>
}

The asp-area="Identity" and asp-page="/Account/Login" Tag Helpers generate a URL like /Identity/Account/Login. This points to ASP.NET Identity's default scaffolded Razor Pages.

Where Are These Razor Pages?​

This project does not contain custom Identity Razor Page files (like Login.cshtml.cs). Instead, in WebApp/Setup/IdentitySetupExtensions.cs:14, the call to .AddDefaultUI() includes the pre-built Identity UI package:

services
    .AddIdentity<AppUser, AppRole>(options => options.SignIn.RequireConfirmedAccount = false)
    .AddDefaultUI()
    .AddEntityFrameworkStores<AppDbContext>()
    .AddDefaultTokenProviders();

.AddDefaultUI() ships a complete set of Razor Pages for Login, Register, Manage, etc. They render forms with email and password fields, CSRF tokens, and "Remember me" checkboxes — all without needing any custom code. The WebApp/Areas/Identity/Pages/_ViewStart.cshtml:2 ensures these pages use the app's shared layout:

@{ Layout = "/Views/Shared/_Layout.cshtml"; }

The API Login (for SPA/Mobile Clients)​

For API consumers, there is no HTML form. Instead, the client sends a JSON POST request to the endpoint defined in WebApp/ApiControllers/Identity/AccountController.cs:75. The request body is defined by the App.DTO/v1/Identity/Login.cs:5 DTO:

public class Login
{
    [EmailAddress] [Required]
    public string Email { get; set; } = default!;

    [MinLength(6)] [MaxLength(100)] [Required]
    public string Password { get; set; } = default!;
}

2. What Happens When the User Submits Credentials​

When a user fills in the Identity login form and clicks "Log in", the default Identity Razor Page (/Identity/Account/Login) handles the POST. Internally it:

  1. Calls SignInManager.PasswordSignInAsync(email, password, rememberMe, lockoutOnFailure)
  2. On success, issues an authentication cookie and redirects to the return URL
  3. On failure, redisplays the form with an error message

This is all handled by the built-in Identity UI — no custom controller code is needed.

The endpoint mapping that makes these Razor Pages reachable is in WebApp/Setup/MiddlewareExtensions.cs:74:

app.MapRazorPages()
    .WithStaticAssets();

Flow B: API (JWT) Login​

An API client sends a POST to POST /api/v1/Account/Login with JSON body. The route is defined by the controller attribute at WebApp/ApiControllers/Identity/AccountController.cs:27:

[ApiVersion("1.0")]
[Route("api/v{version:apiVersion}/[controller]/[action]")]
[ApiController]
public class AccountController : ControllerBase

The WebApp/ApiControllers/Identity/AccountController.cs:75 action receives the request:

[HttpPost]
public async Task<ActionResult<JWTResponse>> Login(
    [FromBody] Login loginInfo,
    [FromQuery] int? jwtExpiresInSeconds,
    [FromQuery] int? refreshTokenExpiresInSeconds)

3. The Authentication Mechanism in Detail​

Step 3a: Find the User​

In WebApp/ApiControllers/Identity/AccountController.cs:85, the first step looks up the user by email:

var appUser = await _userManager.FindByEmailAsync(loginInfo.Email);
if (appUser == null)
{
    _logger.LogWarning("WebApi login failed, email {} not found", loginInfo.Email);
    await Task.Delay(_random.Next(RandomDelayMin, RandomDelayMax));
    return NotFound(new Message(UserPassProblem));
}

Note the random delay (500–5000ms) on failure — this is a timing attack mitigation. An attacker cannot determine whether an email exists based on response time, because both "user not found" and "wrong password" paths include this delay.

Step 3b: Verify the Password​

var result = await _signInManager.CheckPasswordSignInAsync(appUser, loginInfo.Password, false);
if (!result.Succeeded)
{
    await Task.Delay(_random.Next(RandomDelayMin, RandomDelayMax));
    return NotFound(new Message(UserPassProblem));
}

WebApp/ApiControllers/Identity/AccountController.cs:94 internally uses ASP.NET Identity's password hasher. Passwords are never stored in plain text. ASP.NET Identity uses PBKDF2 (with HMAC-SHA256/SHA512) by default to hash passwords on registration. During login, the submitted password is hashed with the same algorithm and compared to the stored hash.

The generic error message "User/Password problem" is used for both "user not found" and "wrong password" — this prevents user enumeration attacks.

Step 3c: Generate JWT Token​

Once credentials are verified, the controller creates a ClaimsPrincipal (containing user claims like ID, email, roles) and generates a JWT:

var claimsPrincipal = await _signInManager.CreateUserPrincipalAsync(appUser);

var jwt = IdentityExtensions.GenerateJwt(
    claimsPrincipal.Claims,
    _configuration.GetValue<string>(SettingsJWTKey)!,
    _configuration.GetValue<string>(SettingsJWTIssuer)!,
    _configuration.GetValue<string>(SettingsJWTAudience)!,
    GetExpirationDateTime(jwtExpiresInSeconds, SettingsJWTExpiresInSeconds)
);

The actual JWT generation happens in WebApp/Helpers/IdentityExtensions.cs:46:

public static string GenerateJwt(
    IEnumerable<Claim> claims, string key, string issuer, string audience, DateTime expires)
{
    var signingKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes(key));
    var signingCredentials = new SigningCredentials(signingKey, SecurityAlgorithms.HmacSha512);

    var token = new JwtSecurityToken(
        issuer: issuer,
        audience: audience,
        claims: claims,
        expires: expires,
        signingCredentials: signingCredentials
    );
    return _jwtSecurityTokenHandler.WriteToken(token);
}

The JWT is signed with HMAC-SHA512 using a symmetric key from configuration. The JWT settings come from WebApp/appsettings.json:18:

"JWT": {
    "Key": "34tfgdfgwe4 gkdhgavnolifg-...",
    "Issuer": "FamilyFeud",
    "Audience": "FamilyFeud",
    "ExpiresInSeconds": 120,
    "RefreshTokenExpiresInSeconds": 604800
}

JWT lifetime is 120 seconds (2 minutes) — intentionally short for security.

Step 3d: Create Refresh Token​

Before returning, the controller also cleans up expired refresh tokens and creates a new one:

// Delete expired tokens
await _context.RefreshTokens
    .Where(t => t.UserId == appUser.Id && t.Expiration < DateTime.UtcNow)
    .ExecuteDeleteAsync();

// Create new refresh token
var refreshToken = new AppRefreshToken()
{
    UserId = appUser.Id,
    Expiration = GetExpirationDateTime(refreshTokenExpiresInSeconds, SettingsJWTRefreshTokenExpiresInSeconds)
};
_context.RefreshTokens.Add(refreshToken);
await _context.SaveChangesAsync();

The response is a App.DTO/v1/Identity/JWTResponse.cs:3:

return Ok(new JWTResponse()
{
    JWT = jwt,
    RefreshToken = refreshToken.RefreshToken
});

4. Where and How Users Are Stored​

Database System​

The application uses PostgreSQL, as configured in WebApp/appsettings.json:3:

"ConnectionStrings": {
    "DefaultConnection": "Server=127.0.0.1;Port=5432;Database=webapp2526s;Username=postgres;Password=postgres"
}

The User Model​

App.Domain/Identity/AppUser.cs:6 extends ASP.NET Identity's IdentityUser<Guid>:

public class AppUser : IdentityUser<Guid>, IBaseEntity
{
    public ICollection<AppRefreshToken>? RefreshTokens { get; set; }
}

By inheriting from IdentityUser<Guid>, AppUser gets all the standard Identity fields automatically. The only custom addition is the RefreshTokens navigation property.

Database Schema (from migration)​

The App.DAL.EF/Migrations/20260227130526_Initial.cs:31 table stores:

ColumnTypePurpose
Iduuid (Guid)Primary key
UserNamevarchar(256)Display name (set to email)
NormalizedUserNamevarchar(256)Uppercase for case-insensitive lookups
Emailvarchar(256)User's email
NormalizedEmailvarchar(256)Uppercase for case-insensitive lookups
EmailConfirmedbooleanWhether email is verified
PasswordHashtextPBKDF2 hashed password
SecurityStamptextChanges when credentials change (invalidates tokens)
ConcurrencyStamptextOptimistic concurrency
PhoneNumbertextOptional phone
PhoneNumberConfirmedbooleanPhone verification flag
TwoFactorEnabledboolean2FA flag
LockoutEndtimestamptzWhen lockout expires
LockoutEnabledbooleanWhether lockout is active
AccessFailedCountintFailed login attempts counter

Refresh Token Model​

App.Domain/Identity/AppRefreshToken.cs:3 stores JWT refresh tokens:

public class AppRefreshToken : BaseEntity
{
    public string RefreshToken { get; set; } = Guid.NewGuid().ToString();
    public DateTime Expiration { get; set; } = DateTime.UtcNow.AddDays(7);
    public string? PreviousRefreshToken { get; set; }
    public DateTime PreviousExpiration { get; set; } = DateTime.UtcNow.AddDays(7);
    public Guid UserId { get; set; }
    public AppUser? User { get; set; }
}

The PreviousRefreshToken/PreviousExpiration fields support token rotation — when a refresh token is used, the old one is kept briefly (1 minute) to handle race conditions where a client might retry with the old token.

Role Model​

App.Domain/Identity/AppRole.cs:6 is a simple extension:

public class AppRole : IdentityRole<Guid>, IBaseEntity { }

Seed Data​

The application seeds default users and roles at startup. From App.DAL.EF/Seeding/InitialData.cs:5:

public static readonly (string roleName, Guid? id)[] Roles =
[
    ("admin", null), ("user", null), ("root", null),
];

public static readonly (string name, string password, Guid? id, string[] roles)[] Users =
[
    ("akaver@akaver.com", "Kala.Maja.101", null, ["admin", "root", "user"]),
    ("andres.kaver@taltech.ee", "Kala.Maja.101", null, ["admin", "root", "user"]),
];

App.DAL.EF/Seeding/AppDataInit.cs:24 creates these users and roles via UserManager.CreateAsync(user, password), which automatically hashes the password.

5. How the Application Connects to the Database​

Database Configuration​

In WebApp/Setup/DatabaseExtensions.cs:16, the AppDbContext is registered with PostgreSQL (via Npgsql):

services.AddDbContext<AppDbContext>(options =>
{
    options.UseNpgsql(
            connectionString,
            o => o.UseQuerySplittingBehavior(QuerySplittingBehavior.SplitQuery))
        .ConfigureWarnings(w =>
            w.Throw(RelationalEventId.MultipleCollectionIncludeWarning))
        .UseQueryTrackingBehavior(QueryTrackingBehavior.NoTrackingWithIdentityResolution);
});

The DbContext​

App.DAL.EF/AppDbContext.cs:10 inherits from IdentityDbContext<AppUser, AppRole, Guid>, which is EF Core's specialized DbContext for Identity. This automatically creates DbSets for all Identity tables (Users, Roles, UserRoles, Claims, etc.):

public class AppDbContext(DbContextOptions<AppDbContext> options)
    : IdentityDbContext<AppUser, AppRole, Guid>(options), IDataProtectionKeyContext
{
    public DbSet<Person> Persons { get; set; }
    public DbSet<AppRefreshToken> RefreshTokens { get; set; }
    public DbSet<DataProtectionKey> DataProtectionKeys { get; set; }
}

ORM: Entity Framework Core​

The application uses Entity Framework Core as its ORM. It maps C# classes to PostgreSQL tables automatically. The UserManager<AppUser> and SignInManager<AppUser> services (provided by ASP.NET Identity) internally use AppDbContext to read/write user data. You never write raw SQL for login — Identity handles all queries.

Service Registration Chain​

In WebApp/Program.cs:7, the boot sequence is:

builder.Services.AddAppDatabase(builder.Configuration, builder.Environment);  // EF Core + PostgreSQL
builder.Services.AddAppIdentity();  // Identity + Default UI + Token Providers

6. What Happens After Successful Authentication​

After SignInManager.PasswordSignInAsync() succeeds, ASP.NET Identity:

  1. Creates an encrypted authentication cookie containing the user's claims
  2. Sends it in the HTTP response with Set-Cookie
  3. Redirects to the return URL (or home page)

On subsequent requests, the cookie is sent automatically by the browser. The middleware pipeline in WebApp/Setup/MiddlewareExtensions.cs:35 calls:

app.UseAuthorization();

This reads the cookie, reconstructs the ClaimsPrincipal, and populates HttpContext.User. Protected pages/controllers decorated with [Authorize] can then check User.Identity.IsAuthenticated.

JWT Flow (API)​

After the API login succeeds, the client receives:

{
    "jwt": "eyJhbG...",
    "refreshToken": "3f2a4b5c-..."
}

The client stores these and includes the JWT in the Authorization: Bearer <jwt> header on subsequent API requests. The JWT is valid for 120 seconds. When it expires, the client calls POST /api/v1/Account/RenewRefreshToken with the expired JWT + refresh token to get a new pair.

Handling Failed Login Attempts​

API flow: The controller returns 404 Not Found with a generic "User/Password problem" message plus a random delay:

await Task.Delay(_random.Next(500, 5000));
return NotFound(new Message(UserPassProblem));

Cookie flow: The default Identity UI redisplays the login page with an "Invalid login attempt" error message.

Logout​

Cookie flow: The logout form in WebApp/Views/Shared/_LoginPartial.cshtml:13 POSTs to the Identity logout page, which clears the authentication cookie.

API flow: The WebApp/ApiControllers/Identity/AccountController.cs:343 action (which requires JWT authentication) deletes the user's refresh tokens from the database. The JWT itself is not server-side invalidated — it remains valid until it naturally expires (max 2 minutes):

[Authorize(AuthenticationSchemes = JwtBearerDefaults.AuthenticationScheme)]
[HttpPost]
public async Task<ActionResult> Logout([FromBody] LogoutInfo logout)
{
    // Deletes matching refresh tokens from DB
}

Rate Limiting​

There is no explicit rate-limiting middleware. However, the random delay on failed logins (500–5000ms) serves as a basic brute-force deterrent for the API path.

Architecture Diagram​

Summary Table​

AspectCookie FlowJWT/API Flow
UIASP.NET Identity Default UI Razor PagesNo UI — JSON API
Endpoint/Identity/Account/LoginPOST /api/v1/Account/Login
Auth mechanismEncrypted cookieJWT (HMAC-SHA512) + Refresh Token
Session durationCookie lifetime (configurable)JWT: 120s, Refresh: 7 days
Password storagePBKDF2 hash in AspNetUsers.PasswordHashSame
DatabasePostgreSQL via EF CoreSame
Error handlingForm re-render with error message404 + generic message + random delay
LogoutClear cookie via Identity pageDelete refresh tokens from DB

based on this codebase, explain how typical web request is handled. how is data parsed from post request, how will the method in code get the actual data into strongly typed structures? what are best practices to organize my code? give me typical keywords from software architecture, are they implemented here? is there anything wrong with this codebase? Keep it simple, explain all acronyms, explain all concepts.

Analyze this codebase thoroughly and explain the complete lifecycle of a typical web request from the moment it arrives at the server to the moment a response is sent back to the client. Trace the exact path through the code, referencing specific files, classes, and methods wherever possible.

Explain in detail how data from an HTTP POST request is parsed and transformed. Walk through the mechanism by which raw incoming data such as JSON or form data is deserialized and mapped into strongly typed classes or structures in the code. Identify the specific libraries, attributes, model binding techniques, or custom parsers involved in this process and explain how they work step by step.

Provide concrete recommendations for how I should organize my code in this project. Explain what a well-structured project layout looks like and why, covering concepts such as separation of concerns, which means keeping different responsibilities like data access, business logic, and presentation in distinct layers so they do not become tangled together. Cover the repository pattern, which abstracts data access behind an interface. Cover dependency injection, which means supplying a class with its dependencies from the outside rather than having it create them internally. Cover middleware, which refers to components that sit in the request pipeline and process requests and responses before or after the main application logic. Cover SOLID principles, which are five design principles aimed at making software more maintainable and flexible, and explain each letter. Cover domain-driven design, which is an approach to structuring code around the core business concepts. Cover CQRS, which stands for Command Query Responsibility Segregation and means separating read operations from write operations. Cover the unit of work pattern, which groups multiple data operations into a single transaction. For each of these concepts and any other relevant software architecture terms, explicitly state whether they are implemented in this codebase, partially implemented, or entirely absent, and point to the specific code that demonstrates this.

Perform a critical review of the codebase and identify anything that is wrong, suboptimal, or risky. Look for issues such as missing input validation, poor error handling, security vulnerabilities, tight coupling between components, violation of the architectural principles listed above, inconsistent patterns, code duplication, performance concerns, and anything else that stands out. For each issue found, explain why it is a problem and suggest a specific improvement.

Keep all explanations simple and accessible. Every time you use a technical term, acronym, or concept that a beginner might not know, define it clearly in plain language the first time you mention it.

Comprehensive Codebase Analysis — ASP.NET Core Web Application

Table of Contents​

  1. Project Structure Overview
  2. Complete Lifecycle of a Web Request
  3. How POST Data Is Parsed and Mapped (Model Binding)
  4. Architectural Patterns Assessment
  5. Critical Review and Issues

1. Project Structure Overview​

This is an ASP.NET Core web application (a framework for building web servers in C#) using a layered architecture (meaning the code is organized into separate projects, each handling a different responsibility). Here is what each project does:

┌─────────────────────────────────────────────────────────────────┐
│                        WebApp (Presentation)                     │
│  Controllers, Views, API Controllers, Setup, Middleware          │
├─────────────────────────────────────────────────────────────────┤
│                    App.DTO (Data Transfer Objects)                │
│  Shapes of data sent to/from the API                             │
├─────────────────────────────────────────────────────────────────┤
│                     App.BLL (Business Logic)                     │
│  Currently empty — placeholder for future business rules         │
├─────────────────────────────────────────────────────────────────┤
│        App.Contracts.DAL (Data Access Interfaces)                │
│  Interfaces that define what the data layer must provide         │
├─────────────────────────────────────────────────────────────────┤
│          App.DAL.EF (Data Access Implementation)                 │
│  Entity Framework Core repositories, DbContext, migrations       │
├─────────────────────────────────────────────────────────────────┤
│                    App.Domain (Entities)                          │
│  The core data classes: Person, AppUser, etc.                    │
├─────────────────────────────────────────────────────────────────┤
│      Base.Contracts.Domain / Base.Contracts.DAL                  │
│  Reusable interfaces (IBaseEntity, IRepository, IBaseUOW)        │
├─────────────────────────────────────────────────────────────────┤
│                     Base.DAL.EF                                  │
│  Generic base implementations for repositories and UoW           │
├─────────────────────────────────────────────────────────────────┤
│          App.Resources / Base.Resources                          │
│  Localization (translated strings for UI)                        │
└─────────────────────────────────────────────────────────────────┘

2. Complete Lifecycle of a Web Request​

I will trace two concrete examples: an MVC form POST (creating a Person) and a JSON API POST (logging in).

2.1 MVC Form POST — Creating a Person​

Step-by-step walkthrough:

Step 1: The request arrives at Kestrel — Kestrel is the built-in ASP.NET Core web server. It receives the raw HTTP POST request containing form-encoded data like FirstName=John&LastName=Doe.

Step 2: The middleware pipeline processes the request. The pipeline is configured in WebApp/Setup/MiddlewareExtensions.cs:13. Each middleware is a component that sits in the request pipeline and can inspect, modify, or short-circuit the request before the next component sees it. The order matters:

  1. UseForwardedHeaders() (line 15) — if the app is behind a reverse proxy (like Nginx), this reads the X-Forwarded-For headers to know the real client IP address
  2. UseRequestLocalization() (line 17) — determines the user's language preference from query string, cookies, or the Accept-Language header, configured in WebApp/Setup/LocalizationExtensions.cs:14
  3. UseMigrationsEndPoint() (line 23, dev only) — a development tool that shows a page to apply database migrations
  4. UseHttpsRedirection() (line 32) — redirects HTTP requests to HTTPS
  5. UseRouting() (line 33) — examines the URL and HTTP method to decide which controller action to call
  6. UseAuthorization() (line 35) — checks if the current user is allowed to access the matched endpoint

Step 3: Route matching. The route templates are defined in WebApp/Setup/MiddlewareExtensions.cs:60. The pattern {controller=Home}/{action=Index}/{id?} at line 71 means the URL /Persons/Create maps to WebApp/Controllers/PersonsController.cs:53.

Step 4: Model Binding (explained in detail in Section 3 below). ASP.NET Core reads the form data and creates a App.Domain/Person.cs:5 object.

Step 5: The controller action executes. In WebApp/Controllers/PersonsController.cs:53:

  • Line 55: ModelState.IsValid checks if the validation rules (like [MaxLength(64)]) passed
  • Line 58: _uow.Persons.Add(person) calls the repository to track the new entity
  • Line 59: await _uow.SaveChangesAsync() persists the data to the database
  • Line 60: RedirectToAction(nameof(Index)) sends a 302 redirect response

Step 6: The response travels back through the middleware pipeline in reverse order and is sent to the browser.

2.2 JSON API POST — Login​

The API controller WebApp/ApiControllers/Identity/AccountController.cs:29 is decorated with [ApiController] (line 28) and [Route("api/v{version:apiVersion}/[controller]/[action]")] (line 27). The [ApiController] attribute enables automatic model validation and automatic 400 responses for invalid models.

The WebApp/ApiControllers/Identity/AccountController.cs:76 attribute on the Login parameter tells ASP.NET Core to read the JSON request body and deserialize it using System.Text.Json into the App.DTO/v1/Identity/Login.cs:5 DTO class.

3. How POST Data Is Parsed and Mapped (Model Binding)​

Model binding is the process by which ASP.NET Core takes raw incoming data (form fields, JSON bodies, query strings, route parameters) and converts it into strongly typed C# objects that your controller methods receive as parameters.

3.1 MVC Form Data Binding (the Person Create example)​

When a browser submits the form in WebApp/Views/Persons/Create.cshtml:1, the data arrives as:

Content-Type: application/x-www-form-urlencoded
FirstName=John&LastName=Doe

The controller method signature is:

[HttpPost]
[ValidateAntiForgeryToken]
public async Task<IActionResult> Create([Bind("FirstName,LastName,Id")] Person person)

at WebApp/Controllers/PersonsController.cs:53.

Here is exactly what happens:

  1. The [HttpPost] attribute tells the routing system this method only handles POST requests
  2. The [ValidateAntiForgeryToken] attribute is an anti-CSRF (Cross-Site Request Forgery) middleware — it verifies that the request includes a token proving it came from your form, not a malicious third-party site. The token is generated by the <form asp-action="Create"> tag helper in the view.
  3. The [Bind("FirstName,LastName,Id")] attribute is a security feature called allow-listing — it means "only bind these three properties from the incoming data, ignore everything else." This prevents overposting attacks where a malicious user adds extra form fields (e.g., IsAdmin=true) to set properties they should not be able to modify.
  4. ASP.NET Core's ComplexObjectModelBinder kicks in:
    • It creates a new Person instance
    • For each allowed property (FirstName, LastName, Id), it looks in the form data for a matching key
    • It uses TypeConverter to convert the string "John" into the string property, and the GUID string into a Guid property
    • It applies data annotations (attributes like [MaxLength(64)] on App.Domain/Person.cs:7) and records any validation errors in ModelState
  5. ModelState.IsValid at WebApp/Controllers/PersonsController.cs:55 returns true only if all validation rules passed

3.2 JSON API Body Binding (the Login example)​

When a client sends:

POST /api/v1/Account/Login
Content-Type: application/json
{"email": "user@example.com", "password": "secret"}
  1. The [FromBody] attribute on WebApp/ApiControllers/Identity/AccountController.cs:76 tells ASP.NET Core to use an input formatter — specifically the SystemTextJsonInputFormatter
  2. System.Text.Json (the built-in .NET JSON library) reads the request body stream and deserializes it into a App.DTO/v1/Identity/Login.cs:5 object
  3. The JSON options configured in WebApp/Setup/WebApiExtensions.cs:15 at lines 18-24 control how property names map: PropertyNamingPolicy = JsonNamingPolicy.CamelCase means "email" in JSON maps to Email in C#
  4. Data Annotations like [Required], [EmailAddress], and [MaxLength(256)] on App.DTO/v1/Identity/Login.cs:7 are validated automatically because of the [ApiController] attribute. If validation fails, ASP.NET Core returns a 400 Bad Request before the action method even runs

3.3 Query String Binding​

The [FromQuery] attribute on parameters like jwtExpiresInSeconds at WebApp/ApiControllers/Identity/AccountController.cs:79 tells the model binder to read from the URL query string, e.g., ?jwtExpiresInSeconds=300.

3.4 Route Parameter Binding​

In WebApp/Controllers/PersonsController.cs:88, the id parameter is bound from the URL route {id?} defined in the route template at WebApp/Setup/MiddlewareExtensions.cs:71.

4. Architectural Patterns Assessment​

4.1 Separation of Concerns​

Definition: Keeping different responsibilities (data access, business logic, presentation) in distinct layers so they do not become tangled together.

Status: ✅ Partially Implemented

The project is split into many projects with clear responsibilities:

  • Domain (App.Domain/Person.cs) — entity definitions
  • Data Access (App.DAL.EF/AppDbContext.cs) — database interaction
  • Contracts (App.Contracts.DAL/IAppUOW.cs) — interfaces
  • Presentation (WebApp/Program.cs) — controllers and views
  • DTOs (App.DTO/v1/Identity/Login.cs) — data transfer objects for the API

However, the Business Logic Layer (App.BLL/App.BLL.csproj) is empty. This means business logic is either absent (the app is simple CRUD) or leaking into controllers. The WebApp/ApiControllers/Identity/AccountController.cs:29 is a clear example — JWT generation, token cleanup, and authentication logic are all in the controller (387 lines).

4.2 Repository Pattern​

Definition: Abstracting data access behind an interface, so the rest of the code does not need to know whether data comes from a database, a file, or a web service.

Status: ✅ Implemented

The repository pattern is present at two levels:

  • Base layer: Base.Contracts.DAL/IRepository.cs:5 defines generic CRUD operations. Base.DAL.EF/BaseRepository.cs:7 provides the default Entity Framework implementation.
  • App layer: App.Contracts.DAL/IPersonRepository.cs:6 extends the base with domain-specific queries like FindByNameAsync. App.DAL.EF/Repositories/PersonRepository.cs:8 implements it.

WebApp/Controllers/PersonsController.cs:9 depends on IAppUOW (the interface), not on the concrete repository — this is correct.

4.3 Dependency Injection (DI)​

Definition: Supplying a class with its dependencies from the outside rather than having it create them internally. Instead of a controller saying new PersonRepository(), the framework gives it one automatically.

Status: ✅ Implemented

DI is configured in multiple setup extension methods:

  • WebApp/Setup/DatabaseExtensions.cs:16 registers AppDbContext and IAppUOW → AppUOW (line 49: services.AddScoped<IAppUOW, AppUOW>())
  • WebApp/Setup/IdentitySetupExtensions.cs:10 registers ASP.NET Identity services
  • WebApp/Setup/WebApiExtensions.cs:15 registers MVC controllers
  • WebApp/Helpers/AppNameService.cs:6 is registered as a singleton at WebApp/Program.cs:10

Controllers receive their dependencies through constructor injection:

public PersonsController(IAppUOW uow) // line 13

4.4 Middleware​

Definition: Components that sit in the request pipeline and process requests and responses before or after the main application logic.

Status: ✅ Implemented

The middleware pipeline is configured in WebApp/Setup/MiddlewareExtensions.cs:13:

  • UseForwardedHeaders() — reverse proxy support
  • UseRequestLocalization() — culture/language selection
  • UseHttpsRedirection() — HTTP→HTTPS redirect
  • UseRouting() — URL matching
  • UseAuthorization() — access control

Missing: There is no custom error-handling middleware, no request logging middleware, and no rate-limiting middleware.

4.5 SOLID Principles​

SOLID is an acronym for five design principles that help make software more maintainable:

S — Single Responsibility Principle (SRP)​

Definition: A class should have only one reason to change — it should do one thing.

Status: ⚠️ Partially followed

  • ✅ App.DAL.EF/Repositories/PersonRepository.cs:8 only handles Person data access
  • ✅ WebApp/Helpers/AppNameService.cs:6 only handles the app name
  • ❌ WebApp/ApiControllers/Identity/AccountController.cs:29 handles login, registration, token renewal, logout, JWT generation config, and token cleanup — at least 3-4 separate responsibilities
  • ❌ WebApp/Controllers/HomeController.cs:13 mixes page rendering, HTMX response, language switching, and error handling

O — Open/Closed Principle (OCP)​

Definition: Software entities should be open for extension but closed for modification — you should be able to add new behavior without changing existing code.

Status: ✅ Partially followed

  • ✅ Base.DAL.EF/BaseRepository.cs:7 uses virtual methods that can be overridden (e.g., PersonRepository can customize behavior)
  • ✅ The generic IRepository<TEntity> allows new entity types without modifying the base
  • ❌ Adding a new entity currently requires modifying App.DAL.EF/AppUOW.cs:8 and App.Contracts.DAL/IAppUOW.cs:5 (not truly "closed")

L — Liskov Substitution Principle (LSP)​

Definition: Objects of a derived class should be usable wherever objects of the base class are expected, without breaking the program.

Status: ✅ Followed

  • App.Domain/Person.cs:5 extends App.Domain/BaseEntity.cs:5 which implements Base.Contracts.Domain/IBaseEntity.cs:3 — all substitutable
  • App.Domain/Identity/AppUser.cs:6 extends IdentityUser<Guid> and implements IBaseEntity

I — Interface Segregation Principle (ISP)​

Definition: Clients should not be forced to depend on interfaces they do not use — keep interfaces small and focused.

Status: ✅ Followed

  • Base.Contracts.DAL/IBaseUOW.cs:3 has only SaveChangesAsync()
  • Base.Contracts.Domain/IBaseEntity.cs:3 has only Id
  • Base.Contracts.DAL/IRepository.cs:5 has only the 6 essential CRUD methods

D — Dependency Inversion Principle (DIP)​

Definition: High-level modules should not depend on low-level modules; both should depend on abstractions (interfaces).

Status: ⚠️ Partially followed

  • ✅ WebApp/Controllers/PersonsController.cs:11 depends on IAppUOW (interface), not AppUOW (concrete class)
  • ❌ WebApp/Controllers/HomeController.cs:19 depends directly on AppDbContext (concrete class) instead of an interface
  • ❌ WebApp/ApiControllers/Identity/AccountController.cs:36 depends directly on AppDbContext (concrete class at line 36) to manipulate refresh tokens
  • ❌ WebApp/Areas/Root/Controllers/UsersController.cs:23 depends directly on AppDbContext

4.6 Domain-Driven Design (DDD)​

Definition: An approach to structuring code around the core business concepts. The domain model is the central artifact, and all other layers serve it.

Status: ❌ Mostly absent

  • The App.Domain/Person.cs project exists and contains entities, which is a start
  • But the domain entities are anemic (a term meaning they contain only data properties, with no business behavior/methods). App.Domain/Person.cs:5 has only FirstName and LastName — no methods, no domain logic
  • There are no Value Objects (immutable objects defined by their properties, like an Address or Money type), no Aggregates (clusters of entities treated as a unit), no Domain Events, and no Domain Services
  • The App.Domain/LangStr.cs:4 class is actually an interesting domain concept — a multi-language string type — but it is more of a utility than a DDD building block

4.7 CQRS (Command Query Responsibility Segregation)​

Definition: Separating read operations (queries) from write operations (commands) — using different models or paths for reading data versus modifying it.

Status: ❌ Not implemented

The same Base.Contracts.DAL/IRepository.cs:5 interface handles both reads (GetAllAsync, GetByIdAsync) and writes (Add, Update, Remove). The same WebApp/Controllers/PersonsController.cs:9 handles both reading and writing. There is no separation between command models and query models.

4.8 Unit of Work Pattern​

Definition: Grouping multiple data operations into a single transaction so they either all succeed or all fail together.

Status: ✅ Implemented

  • Base.Contracts.DAL/IBaseUOW.cs:3 defines SaveChangesAsync()
  • Base.DAL.EF/BaseUOW.cs:6 wraps EF Core's DbContext.SaveChangesAsync()
  • App.DAL.EF/AppUOW.cs:8 extends the base and exposes the Persons repository
  • Controllers call _uow.SaveChangesAsync() after all operations (e.g., WebApp/Controllers/PersonsController.cs:59)

Limitation: The App.DAL.EF/AppUOW.cs:12 constructor creates repositories eagerly (line 14: Persons = new PersonRepository(context)). If you have 20 repositories, all 20 are instantiated on every request even if you only need one. A lazy instantiation pattern would be more efficient.

5. Critical Review and Issues​

🔴 Critical Issues​

Issue 1: JWT Secret Key Hardcoded in appsettings.json​

File: WebApp/appsettings.json:19

"Key": "34tfgdfgwe4 gkdhgavnolifg-.sdclkznsvdkjs!w49t8ysf..."

Why it's a problem: This secret key is committed to source control. Anyone who can read the repository can forge valid JWT tokens and impersonate any user. This is a critical security vulnerability. Fix: Move the key to environment variables or a secrets manager. Use dotnet user-secrets for development and environment variables in production.

Issue 2: Seed Passwords Hardcoded in Source​

File: App.DAL.EF/Seeding/InitialData.cs:16

("akaver@akaver.com", "Kala.Maja.101", null, ["admin", "root", "user"]),

Why it's a problem: Real email addresses and passwords in source code are a security risk. If this is a teaching project, it's less severe, but it's still bad practice. Fix: Move seed credentials to environment variables or user secrets.

Issue 3: Password Logged in Plain Text​

File: WebApp/ApiControllers/Identity/AccountController.cs:97

_logger.LogWarning("WebApi login failed, password {} for email {} was wrong", loginInfo.Password, loginInfo.Email);

Why it's a problem: This writes the user's actual password into log files. Anyone with access to logs can see users' passwords. This is a severe security vulnerability. Fix: Remove the password from the log message entirely. Log only the email and the fact that login failed.

Issue 4: CORS Policy Allows Everything​

File: WebApp/Setup/WebApiExtensions.cs:54

policy.AllowAnyOrigin().AllowAnyHeader().AllowAnyMethod()

Why it's a problem: CORS (Cross-Origin Resource Sharing) controls which websites can make requests to your API. AllowAnyOrigin means any website in the world can call your API from the browser. Combined with the JWT auth, this is a security risk. Fix: Restrict to known origins in production (e.g., your frontend domain). Keep the permissive policy only for development.

Note: The CORS policy is defined but never actually applied in the middleware pipeline. Neither app.UseCors() nor [EnableCors] appears in the middleware setup. This means the CORS configuration is effectively dead code.

🟠 Significant Issues​

Issue 5: AccountController Bypasses UoW, Uses DbContext Directly​

File: WebApp/ApiControllers/Identity/AccountController.cs:36

private readonly AppDbContext _context;

Why it's a problem: The controller directly depends on AppDbContext (the concrete database class) rather than going through IAppUOW. This violates the Dependency Inversion Principle and makes the controller harder to test. It also bypasses the repository pattern established elsewhere. Fix: Create an IRefreshTokenRepository and add refresh token operations to IAppUOW.

Issue 6: HomeController Depends on AppDbContext But Doesn't Use It​

File: WebApp/Controllers/HomeController.cs:19

public HomeController(AppDbContext context, ILogger<HomeController> logger)

Why it's a problem: _context is injected but never used in any action method. This creates an unnecessary dependency, which means an AppDbContext is instantiated (and a database connection potentially opened) for every home page request unnecessarily. Fix: Remove the AppDbContext dependency from HomeController.

Issue 7: Static Mutable State in HomeController​

File: WebApp/Controllers/HomeController.cs:17

private static int _counter = 0;

Why it's a problem: static means this variable is shared across all requests and all users. In a web server handling concurrent requests, incrementing _counter++ at WebApp/Controllers/HomeController.cs:33 is a race condition — two requests could read the same value simultaneously. If you deploy multiple server instances, each has its own counter, leading to inconsistent behavior. Fix: If you need a counter, use Interlocked.Increment(ref _counter) for thread safety, or store the value in a database.

Issue 8: No Business Logic Layer​

File: App.BLL/App.BLL.csproj Why it's a problem: The BLL project is empty. All logic lives in controllers. As the application grows, controllers become bloated "god classes" that handle validation, authorization, business rules, and orchestration. The WebApp/ApiControllers/Identity/AccountController.cs:29 at 387 lines is already showing this problem. Fix: Create service classes in the BLL layer. For example, an IAuthService with LoginAsync(), RegisterAsync(), RenewTokenAsync(), and LogoutAsync() methods. Controllers should only translate HTTP concepts (requests, responses, status codes) into calls to these services.

Issue 9: No Input Validation on MVC Controllers​

File: WebApp/Controllers/PersonsController.cs:53 Why it's a problem: While the [Bind] attribute prevents overposting, there are no validation attributes beyond [MaxLength(64)] on App.Domain/Person.cs:7. There is no [Required] on FirstName or LastName, meaning empty strings are accepted. There's no regex or custom validation for name formats. Fix: Add [Required] and consider [MinLength(1)] to the App.Domain/Person.cs properties. Better yet, use separate ViewModels/DTOs for form input instead of binding directly to domain entities.

Issue 10: Domain Entities Used as View Models​

Files: WebApp/Views/Persons/Create.cshtml:1, WebApp/Controllers/PersonsController.cs:53

@model App.Domain.Person

Why it's a problem: The Razor view and the [Bind] attribute directly reference the domain entity Person. This creates tight coupling between the UI layer and the domain. If you add a navigation property or internal field to Person, you risk accidentally exposing or binding it. The [Bind] attribute is a fragile allowlist — you must remember to update it every time the entity changes. Fix: Create PersonCreateViewModel and PersonEditViewModel classes in the WebApp/ViewModels folder. Map between ViewModels and domain entities in the controller (or better, in a service layer).

Issue 11: GetByIdAsync Returns Null-Forgiving ! Without Null Check​

File: Base.DAL.EF/BaseRepository.cs:48

return (await RepositoryDbSet.FindAsync(id))!;

Why it's a problem: The ! operator tells the compiler "trust me, this is not null" but FindAsync can return null if the entity doesn't exist. This means callers get a null disguised as a non-null type, leading to NullReferenceException at runtime. In WebApp/Controllers/PersonsController.cs:32 line 34 checks for null, but the repository's return type signature lies about nullability. Fix: Change the return type to Task<TEntity?> and handle nulls explicitly in callers.

Issue 12: RemoveAsync Doesn't Handle Missing Entities​

File: Base.DAL.EF/BaseRepository.cs:32

var entity = await GetByIdAsync(id);
return RepositoryDbSet.Remove(entity!).Entity;

Why it's a problem: If the entity doesn't exist, GetByIdAsync returns null (disguised as non-null), then Remove(null!) throws an ArgumentNullException. The controller at WebApp/Controllers/PersonsController.cs:130 calls RemoveAsync without checking if the entity exists first. Fix: Return a nullable type or throw a specific NotFoundException that the controller can catch.

Issue 13: Forwarded Headers Trust All IPs​

File: WebApp/Setup/WebApiExtensions.cs:36

options.KnownIPNetworks.AddRange(new List<IPNetwork>() {
    new IPNetwork(IPAddress.Any, 0),
    new IPNetwork(IPAddress.IPv6Any, 0)
});

Why it's a problem: This trusts forwarded headers from any IP address. An attacker can send fake X-Forwarded-For headers to spoof their IP address, potentially bypassing IP-based rate limiting or logging. Fix: Only trust the specific IP addresses of your known reverse proxies.

Issue 14: GetExpirationDateTime Allows User to Set Custom Expiration​

File: WebApp/ApiControllers/Identity/AccountController.cs:378 Why it's a problem: The [FromQuery] int? jwtExpiresInSeconds parameter on login/register endpoints allows callers to request custom JWT expiration times. While the code caps it at the configured maximum (line 381), it still allows shorter expirations. More concerning: the if (expiresInSeconds <= 0) expiresInSeconds = int.MaxValue; at line 380 means sending 0 or a negative number gives you a token that expires in ~68 years. Fix: Remove the user-controllable expiration parameters or limit them more carefully.

🟡 Minor Issues​

Issue 15: Namespace Inconsistency in DTO Project​

File: App.DTO/v1/Message.cs:1 uses namespace App.Dto.v1 while App.DTO/v1/Identity/Login.cs:3 uses namespace App.DTO.v1.Identity. The casing difference (Dto vs DTO) causes references like WebApp/ApiControllers/Identity/AccountController.cs:90 to use App.Dto.v1.Message while importing App.DTO.v1.Identity. Fix: Standardize all namespaces to use App.DTO.v1.

Issue 16: Missing UseCors() in Middleware Pipeline​

The CORS policy "CorsAllowAll" is configured at WebApp/Setup/WebApiExtensions.cs:52 but never applied via app.UseCors("CorsAllowAll") in the middleware pipeline at WebApp/Setup/MiddlewareExtensions.cs. This means the CORS configuration is dead code and cross-origin requests will be blocked by browsers. Fix: Add app.UseCors("CorsAllowAll") in the middleware pipeline between UseRouting() and UseAuthorization().

Issue 17: Missing UseStaticFiles() in Middleware​

File: WebApp/Setup/MiddlewareExtensions.cs:13 Static file serving via MapStaticAssets() is at WebApp/Setup/MiddlewareExtensions.cs:62, but the conventional UseStaticFiles() middleware is absent. MapStaticAssets() is a newer .NET feature that might handle this, but it is worth verifying that static files (CSS, JS, images) are being served correctly.

Issue 18: Eager Repository Instantiation in UoW​

File: App.DAL.EF/AppUOW.cs:14

Persons = new PersonRepository(context);

Why it's a problem: Every repository is created in the constructor, even if the current request doesn't need it. With many entities, this wastes memory and CPU. Fix: Use a lazy pattern:

private IPersonRepository? _persons;
public IPersonRepository Persons => _persons ??= new PersonRepository(UOWDbContext);

Issue 19: async Methods Without await​

File: WebApp/Controllers/HomeController.cs:25

public async Task<IActionResult> Index()
{
    return View();
}

Why it's a problem: This method is marked async but contains no await. The compiler generates unnecessary state machine overhead. Fix: Remove async and return Task.FromResult<IActionResult>(View()) or just make it synchronous.

Issue 20: WaitDbConnection Infinite Loop Risk​

File: WebApp/Setup/AppDataInitExtensions.cs:67

while (true) { ... }

Why it's a problem: If the database server is permanently unavailable for a reason not caught by PostgresException, this loop runs forever and the application never starts. Fix: Add a maximum retry count and a total timeout.

Issue 21: Missing Authorization on PersonsController​

File: WebApp/Controllers/PersonsController.cs:9 Why it's a problem: There is no [Authorize] attribute on the controller. Anyone, including unauthenticated users, can create, edit, and delete Persons. The root admin area is correctly protected with [Authorize(Roles = "root")] at WebApp/Areas/Root/Controllers/HomeController.cs:9, but PersonsController is wide open. Fix: Add [Authorize] to the controller or to specific actions.

Issue 22: Test Assertions Not Checking Login Response​

File: WebApp.Tests/Integration/Api/IntegrationTestIdentity.cs:94

response.EnsureSuccessStatusCode(); // should be loginResponse

Why it's a problem: Line 94 checks response (the registration response) instead of loginResponse (the login response). The login response is never verified for success status. Fix: Change to loginResponse.EnsureSuccessStatusCode().

Summary Table​

Pattern/ConceptStatusKey Evidence
Separation of Concerns⚠️ PartialProjects exist but BLL empty, controllers too fat
Repository Pattern✅ ImplementedBase.Contracts.DAL/IRepository.cs:5, Base.DAL.EF/BaseRepository.cs:7, App.DAL.EF/Repositories/PersonRepository.cs:8
Dependency Injection✅ ImplementedWebApp/Setup/DatabaseExtensions.cs:49, constructor injection in controllers
Middleware✅ ImplementedWebApp/Setup/MiddlewareExtensions.cs:13, but no custom middleware
SRP (Single Responsibility)⚠️ PartialRepositories are clean; AccountController violates it
OCP (Open/Closed)⚠️ PartialGeneric base classes allow extension; UoW requires modification
LSP (Liskov Substitution)✅ FollowedClean inheritance hierarchy
ISP (Interface Segregation)✅ FollowedSmall, focused interfaces
DIP (Dependency Inversion)⚠️ PartialPersonsController ✅, HomeController/AccountController ❌
Domain-Driven Design❌ AbsentAnemic entities, no value objects, no domain services
CQRS❌ AbsentSame repository for reads and writes
Unit of Work✅ ImplementedBase.Contracts.DAL/IBaseUOW.cs:3, App.DAL.EF/AppUOW.cs:8
Model Binding✅ Built-in[Bind], [FromBody], [FromQuery], data annotations
API Versioning✅ ImplementedWebApp/Setup/WebApiExtensions.cs:67
Localization✅ ImplementedWebApp/Setup/LocalizationExtensions.cs:14, App.Domain/LangStr.cs:4
Testing⚠️ PartialIntegration + unit tests exist but coverage is minimal

Analüüsi põhjalikult seda koodibaasi ja tuvasta kõik kasutusel olevad olulised mustrid, arhitektuurilised lähenemised ning põhitehnoloogiad. Kirjelda iga leitud mustri ja tehnoloogia kohta selle eesmärki, kasutusulatust koodibaasis ning kuidas need omavahel seostuvad. Too välja nii disainimustrid, arhitektuurimustrid kui ka kasutatavad raamistikud, teegid ja tööriistad. Vasta eesti keeles.

Koodibaasi põhjalik analüüs: mustrid, arhitektuur ja tehnoloogiad

1. Ülevaade arhitektuurist​

Projekt on ASP.NET Core .NET 10 veebirakendus, mis järgib kihilist arhitektuuri (Layered / N-Tier Architecture) koos selge vastutuste jaotusega. Lahendus koosneb 13+ projektist, mis on organiseeritud kahte põhigruppi: Base (taaskasutatav infrastruktuur) ja App (rakendusespetsiifiline loogika).

2. Disainimustrid (Design Patterns)​

2.1 Repository muster (Repository Pattern)​

Eesmärk: Abstraheerib andmepääsuloogika domeeniobjektide taga olevast andmebaasist, võimaldades andmeallika vahetamist ilma äriloogikat muutmata.

Kasutusulatust:

  • Baasliides: Base.Contracts.DAL/IRepository.cs:5 — geneeriliste CRUD-operatsioonide liides (Add, Remove, Update, GetAllAsync, GetByIdAsync)
  • Baasimplementatsioon: Base.DAL.EF/BaseRepository.cs:7 — EF Core'il põhinev geneerilise hoidla realisatsioon
  • Konkreetne liides: App.Contracts.DAL/IPersonRepository.cs:6 — lisab domeenispetsiifilise meetodi FindByNameAsync
  • Konkreetne implementatsioon: App.DAL.EF/Repositories/PersonRepository.cs:8 — pärib BaseRepository ja realiseerib IPersonRepository

Seos: Repository muster töötab koos Unit of Work mustriga. Kontrollerid ei loo hoidlaid otse, vaid pöörduvad nende poole läbi UoW.

2.2 Unit of Work muster (Unit of Work Pattern)​

Eesmärk: Koondab kõik andmebaasi muudatused üheks transaktsiooniks, tagab et kõik seotud muudatused salvestatakse atomaarselt.

Kasutusulatust:

  • Baasliides: Base.Contracts.DAL/IBaseUOW.cs:3 — ainult SaveChangesAsync()
  • Baasimplementatsioon: Base.DAL.EF/BaseUOW.cs:6 — delegeerib DbContext.SaveChangesAsync()-le
  • Konkreetne liides: App.Contracts.DAL/IAppUOW.cs:5 — eksponeerib Persons hoidla
  • Konkreetne implementatsioon: App.DAL.EF/AppUOW.cs:8 — loob ja haldab kõiki rakenduse hoidlaid

Seos: WebApp/Controllers/PersonsController.cs:13 saab DI kaudu IAppUOW ja kasutab seda kõigi andmepääsuoperatsioonide jaoks.

2.3 Geneerilise baasklassi muster (Generic Base Class / Template Method)​

Eesmärk: Elimineerib koodi korduse, pakkudes taaskasutatavaid baasklasse geneeriliste tüübiparameetritega.

Kasutusulatust:

  • Base.Contracts.Domain/IBaseEntity.cs:3 → App.Domain/BaseEntity.cs:5 — kõik domeeniobjektid pärivad sellelt Guid Id
  • Base.DAL.EF/BaseRepository.cs:7 — geneerilised CRUD operatsioonid igale olemile
  • Base.DAL.EF/BaseUOW.cs:6 — geneerilise UoW baasfunktsionaalsus

Seos: Kõik App-kihi klassid pärivad Base-kihi geneerilisi baasklasse, luues selge pärilushierarhia.

2.4 Extension Method muster​

Eesmärk: Organiseerib Program.cs konfiguratsioon puhtaks ja modulaarseks, kasutades staatilisi laiendmeetodeid.

Kasutusulatust — 6 eraldi Setup-klassi:

  • WebApp/Setup/DatabaseExtensions.cs:16 — andmebaasi ja UoW registreerimine
  • WebApp/Setup/IdentitySetupExtensions.cs:10 — Identity seadistamine
  • WebApp/Setup/WebApiExtensions.cs:15 — kontrollerite, CORS, versioning, Swagger
  • WebApp/Setup/LocalizationExtensions.cs:14 — lokaliseerimise seadistamine
  • WebApp/Setup/MiddlewareExtensions.cs:13 — pipeline konfigureerimine
  • WebApp/Setup/AppDataInitExtensions.cs:17 — andmete seeding

Seos: Kõik laiendmeetodid kutsutakse välja WebApp/Program.cs:7-st, muutes selle äärmiselt puhtaks (~26 rida).

2.5 Options/Configuration muster (IOptions Pattern)​

Eesmärk: Struktureeritud ligipääs konfiguratsioonile läbi tugevalt tüpiseeritud objektide.

Kasutusulatust:

  • WebApp/ConfigureSwaggerOptions.cs:13 implementeerib IConfigureOptions<SwaggerGenOptions>
  • WebApp/Setup/LocalizationExtensions.cs:24 läbi services.Configure<>()
  • WebApp/Setup/WebApiExtensions.cs:31 läbi services.Configure<>()
  • JWT seaded loetakse IConfiguration-ist WebApp/ApiControllers/Identity/AccountController.cs:42-s

2.6 Dependency Injection (DI) muster​

Eesmärk: Loose coupling komponentide vahel, testitavus, vastutuste selge eraldamine.

Kasutusulatust:

  • WebApp/Setup/DatabaseExtensions.cs:49 registreeritakse Scoped elutsükliga
  • WebApp/Helpers/AppNameService.cs:5 registreeritakse Singletonina
  • Kontrollerid saavad sõltuvused konstruktori kaudu: WebApp/Controllers/PersonsController.cs:13, WebApp/Controllers/HomeController.cs:19
  • Views kasutavad @inject: WebApp/Views/Shared/_Layout.cshtml:3 injekteerib AppNameService

2.7 Data Transfer Object (DTO) muster​

Eesmärk: Eraldab API vastuste/päringute andmemudeli domeenimudelist.

Kasutusulatust — App.DTO projekt:

  • App.DTO/v1/Identity/JWTResponse.cs:3 — JWT autentimise vastus
  • App.DTO/v1/Identity/Login.cs / App.DTO/v1/Identity/Register.cs — sisselogimise/registreerimise päringud
  • App.DTO/v1/Message.cs:3 — universaalne veasõnumite DTO
  • App.DTO/v1/Identity/RefreshTokenModel.cs / App.DTO/v1/Identity/LogoutInfo.cs — tokenipõhised DTO-d
  • DTO-d on versioonitud (v1/ kaust)

3. Arhitektuurimustrid (Architectural Patterns)​

3.1 MVC (Model-View-Controller)​

Eesmärk: Eraldab esitluse, äriloogika ja andmed.

Kasutusulatust:

  • Kontrollerid: WebApp/Controllers/HomeController.cs:13, WebApp/Controllers/PersonsController.cs:9
  • Vaated: Views/Persons/ (Index, Create, Edit, Delete, Details), Views/Home/, Views/Shared/
  • Mudelid: App.Domain olemid + WebApp/ViewModels/ErrorViewModel.cs
  • Areas: WebApp/Areas/Root/Controllers/UsersController.cs:18 ala administreerimiseks ([Area("Root")])

3.2 REST API (koos versioonimisega)​

Eesmärk: Pakub masinloetavat API-t välisklientidele.

Kasutusulatust:

  • WebApp/ApiControllers/Identity/AccountController.cs:29 — [ApiController] + [ApiVersion("1.0")]
  • Marsruutimine: api/v{version:apiVersion}/[controller]/[action]
  • WebApp/Setup/WebApiExtensions.cs:69 — API versioonihaldus URL-i segmendi kaudu
  • Swagger/OpenAPI dokumentatsioon WebApp/ConfigureSwaggerOptions.cs:23-ga

3.3 Clean Architecture / Onion Architecture tunnused​

Eesmärk: Sõltuvuste suund on alati sissepoole — domeenikiht ei sõltu millestki välisest.

Kasutusulatust:

  • Base.Contracts.Domain ja Base.Contracts.DAL — puhtad liidesed ilma infrastruktuuri sõltuvusteta
  • App.Domain sõltub ainult Base.Contracts.Domain-ist
  • App.Contracts.DAL defineerib liidesed, mida implementeerib App.DAL.EF
  • Kontrollerid sõltuvad liidestest (IAppUOW), mitte konkreetsetest klassidest

4. Põhitehnoloogiad ja raamistikud​

4.1 Platvorm ja keel​

TehnoloogiaVersioonEesmärk
.NET10.0Sihtplatvorm (WebApp/WebApp.csproj:4: net10.0)
C#14+Põhikeel (kasutab C# 14 extension süntaksit WebApp/Helpers/IdentityExtensions.cs:13)

4.2 Serveripoolsed raamistikud​

RaamistikKasutus
ASP.NET Core MVCVeebikontrollerid + Razor Views (WebApp/Controllers/PersonsController.cs:9)
ASP.NET Core Web APIREST API kontrollerid (WebApp/ApiControllers/Identity/AccountController.cs:29)
Entity Framework Core 10ORM, migratsioonid, seeding (App.DAL.EF/AppDbContext.cs:10)
ASP.NET Core IdentityKasutajate/rollide haldus (WebApp/Setup/IdentitySetupExtensions.cs:12)
ASP.NET Core LocalizationMitmekeelne tugi (et, en) (WebApp/Setup/LocalizationExtensions.cs:14)

4.3 Andmebaas​

TehnoloogiaKasutus
PostgreSQLTootmisandmebaas (Npgsql provider, WebApp/Setup/DatabaseExtensions.cs:32)
EF Core InMemoryTestimiseks (WebApp.Tests/CustomWebApplicationFactory.cs:33)

4.4 Autentimis- ja turvaraamistikud​

RaamistikKasutus
JWT Bearer AuthenticationAPI autentimine (WebApp/ApiControllers/Identity/AccountController.cs:126)
Refresh Token mehhanismApp.Domain/Identity/AppRefreshToken.cs:3 + token rotation
ASP.NET Core Data ProtectionVõtmete haldus EF kaudu (WebApp/Setup/DatabaseExtensions.cs:47)
CORSLubatud kõik päritolud API jaoks (WebApp/Setup/WebApiExtensions.cs:52)

4.5 API dokumentatsioon ja versioonihaldus​

TeekKasutus
Swashbuckle (Swagger/OpenAPI)API dokumentatsioon (WebApp/ConfigureSwaggerOptions.cs:23)
Asp.VersioningAPI versioonihaldus (WebApp/Setup/WebApiExtensions.cs:69)

4.6 Kliendipoolsed teegid​

TeekVersioonKasutus
Bootstrap(bundled)CSS raamistik (WebApp/Views/Shared/_Layout.cshtml:11)
jQuery(bundled)DOM manipulatsioon + valideerimise tugi
htmx2.0.8Deklaratiivne AJAX (WebApp/libman.json:6, WebApp/Views/Shared/_Layout.cshtml:69)
Alpine.js3.15.4Reaktiivne JS mikroraamistik (WebApp/libman.json:12)
jQuery Validation + UnobtrusiveKliendipoolne vormide valideerimine

4.7 Testimisraamistikud​

TeekKasutus
xUnitTestimisraamistik (WebApp.Tests/Integration/IntegrationTestHomeController.cs:9)
Microsoft.AspNetCore.Mvc.TestingIntegratsioonitestid WebApp.Tests/CustomWebApplicationFactory.cs:13-ga

4.8 Abitööriistad​

TööriistKasutus
LibManKliendipoolsete teekide haldus (WebApp/libman.json)
CsvHelperCSV failide töötlemine (WebApp/WebApp.csproj:22)
X.PagedListLeheküljeline pagineerimine (WebApp/WebApp.csproj:23)

5. Lisaomadused ja -mustrid​

5.1 Mitmekeelsuse tugi (i18n / Localization)​

  • Ressursifailid: App.Resources/Views/Shared/_Layout.resx (inglise) ja App.Resources/Views/Shared/_Layout.et.resx (eesti)
  • LangStr klass: App.Domain/LangStr.cs:4 — kohandatud Dictionary<string,string> mitmekeelsete stringide salvestamiseks andmebaasis JSONB-na
  • Keelevalik: WebApp/Views/Shared/_LanguageSelection.cshtml — dropdown keelevahetuseks
  • Keele seadistamine: WebApp/Controllers/HomeController.cs:42 — küpsisepõhine keelevalik
  • Kultuuripakkujad: QueryString → Cookie → AcceptLanguage header (WebApp/Setup/LocalizationExtensions.cs:34)

5.2 Andmebaasi initsialiseerimine (Seeding)​

  • Konfigureeritav seeding: WebApp/appsettings.json:6 DataInitialization sektsioon kontrollib: DropDatabase, MigrateDatabase, SeedIdentity, SeedData
  • Algandmed: App.DAL.EF/Seeding/InitialData.cs:3 — rollid (admin, user, root) ja algkasutajad
  • Ühenduse ootamine: WebApp/Setup/AppDataInitExtensions.cs:60 — Docker-konteinerite jaoks

5.3 Turvahoiatuste konfiguratsioon​

  • Directory.Build.props — nullable-hoiatused on tõstetud vigadeks (WarningsAsErrors)
  • Cascade delete on keelatud: App.DAL.EF/AppDbContext.cs:27
  • DateTime UTC konversioon: App.DAL.EF/AppDbContext.cs:38 — PostgreSQL ühilduvuse tagamine
  • ValidateAntiForgeryToken CSRF kaitse MVC vormidel
  • Juhuslik viivitus ebaõnnestunud sisselogimisel (WebApp/ApiControllers/Identity/AccountController.cs:89) — timing-rünnakute vastane kaitse

5.4 Areas-põhine modulaarsus​

  • Root ala: WebApp/Areas/Root/Controllers/UsersController.cs:18 — administraatori vaated, [Authorize(Roles = "root")]

6. Kokkuvõttev seostediagramm​

Kokkuvõttes on tegemist hästi struktureeritud, kihilise ASP.NET Core rakendusega, mis järgib tööstuslikke parimaid praktikaid: Repository + Unit of Work andmepääsuks, geneerilised baasklassid koodi taaskasutamiseks, Dependency Injection lahtisidumiseks, DTO-d API piirikihi jaoks, ning Extension Methods puhta konfigureerimise tagamiseks. Projekt toetab nii traditsioonilist MVC-d (Razor Views) kui ka versiooni­tud REST API-t JWT autentimisega.