三层架构同意管理系统中状态检查的职责归属与实现方案咨询

Hey there! Let's work through your consent management system design question—this is a common layering dilemma, so let's break down your options and find a better middle ground.

First, let's unpack the two approaches you've already got on the table:

方案1: 业务层显式检查 #

This approach keeps your business logic front-and-center, which has some clear upsides:

• Transparency: Anyone maintaining the code can immediately see the consent check rule in the service layer—no digging into SQL queries to find hidden logic.
• Flexibility: If the consent check ever gets more complex (e.g., combining HasConsent with a consent expiration date), you can update the service code easily without touching database queries.

But it's not without drawbacks:

• Wasted resources: Using SELECT * pulls back more data than you need (you only really care about Id and HasConsent), which adds unnecessary overhead if the table is large.
• Risk of duplication: If this check is needed in multiple service methods, you might end up repeating the same if (!HasConsent) logic everywhere.

Code Snippets for Reference #

SQL Query:

SELECT * FROM [ApplicationUserMapping] WHERE Uuid = @Uuid AND ApplicationUuid=@ApplicationUuid;

Service Layer Logic:

if (!applicationUserMapping.HasConsent) { 
    // Handle no consent: error messages, logging, etc.
} 
// Proceed with fetching Id and next steps

方案2: 仓储层SQL过滤 #

Shifting the check to the database has performance benefits, but trade-offs in maintainability:

• Performance: The database only returns records where consent is granted, cutting down on data transfer between your app and SQL server.
• Encapsulation: The service layer doesn't need to worry about the consent check—it just gets a valid record (or null if conditions aren't met).

Downsides here:

• Hidden logic: The consent rule is buried in a SQL query, so new team members might miss it unless they dig into the repository code.
• Limited context: If the query returns null, you can't tell if it's because the ApplicationUserMapping doesn't exist or because the user hasn't given consent—you'd need extra queries to distinguish these cases, which negates some performance gains.

SQL Query for Reference #

SELECT * FROM [ApplicationUserMapping] WHERE Uuid = @Uuid AND ApplicationUuid=@ApplicationUuid AND HasConsent = 1;

Let's combine the best parts of both approaches while fixing their flaws. Here's a balanced solution:

1. Repository Layer: Targeted Methods #

Instead of a single "get everything" method or a filtered SELECT *, give your repository two focused methods:

• A method to fetch only the fields you need (no SELECT *!) for consent checking and ID retrieval.
• A method to explicitly check consent status, returning clear context about why a check failed.

Example repository code (C#-style):

// Fetch only critical fields to avoid overloading
ApplicationUserMappingEssentials GetUserMappingEssentials(Guid uuid, Guid applicationUuid);

// Return a clear result type instead of just bool/null
ConsentCheckStatus CheckUserConsent(Guid uuid, Guid applicationUuid);

// Enum to clarify check results
enum ConsentCheckStatus {
    MappingNotFound,
    NoConsentGranted,
    ConsentGranted
}

// Minimal model for essentials
class ApplicationUserMappingEssentials {
    public Guid Id { get; set; }
    public bool HasConsent { get; set; }
}

Corresponding SQL for the check:

SELECT 
    CASE WHEN COUNT(*) = 0 THEN 'MappingNotFound'
         WHEN MAX(CAST(HasConsent AS INT)) = 0 THEN 'NoConsentGranted'
         ELSE 'ConsentGranted'
    END AS ConsentStatus
FROM [ApplicationUserMapping]
WHERE Uuid = @Uuid AND ApplicationUuid = @ApplicationUuid;

2. Service Layer: Clear, Reusable Logic #

In your service layer, use these repository methods to keep logic clean and avoid duplication:

var consentStatus = _userMappingRepository.CheckUserConsent(uuid, applicationUuid);

switch (consentStatus) {
    case ConsentCheckStatus.MappingNotFound:
        // Handle missing user-application mapping (e.g., return 404)
        break;
    case ConsentCheckStatus.NoConsentGranted:
        // Log, return error, redirect to consent flow
        break;
    case ConsentCheckStatus.ConsentGranted:
        // Fetch the essential data and get the Id
        var mappingEssentials = _userMappingRepository.GetUserMappingEssentials(uuid, applicationUuid);
        var targetId = mappingEssentials.Id;
        // Proceed with your business logic
        break;
}

3. Bonus Optimizations #

• Avoid SELECT *: Always fetch only the fields you need—this reduces memory usage and network traffic.
• Centralize consent checks: If multiple service methods need this check, wrap it in a private helper method (e.g., EnsureUserHasConsent()) to avoid repeating code.
• Keep repository focused: The repository handles data access, but the service layer owns the business rules—this keeps your layers aligned with single responsibility principles.

内容的提问来源于stack exchange，提问作者Pepijn Hockers