A Spring JDBC search demo moves role visibility out of a StringBuilder and into Strategy classes

The local officer's query shows where visibility lives in the legacy code. It is one line, `AND d.org_unit_id = :userUnitId`, sitting under `WHERE 1 = 1` ^[8]. `WHERE 1 = 1` exists so that no later append has to know whether it comes first. The method has one `if` per role ^[7], so the boundary exists only on the paths where one of those branches ran.

The chartered unit is where that gets expensive. A local office that reports straight to the national office is visible to a regional supervisor only while the supervisor holds an explicit, dated delegation for it ^[5]. In the legacy method that rule is five `sql.append` calls inside an `else if`, with nothing to call, reuse or test in isolation ^[10]. The post's author wrote: "A search with optional filters and role-based visibility is application logic, and one of its invariants is a security boundary" ^[1].

I agree, with a condition. The composed design is a boundary only if the builder refuses to produce SQL when no visibility strategy has contributed a fragment. The post says the builder enforces the rules ^[2]. The available text of the post ends before the composed code, so how it enforces them is described here, not shown. I would want one test per visibility strategy, with a delegation fixture on each side of its end date.

The performance case is specific to SQL Server. The engine caches one plan per statement text ^[12]. The legacy text never changes, so every filter combination shares a plan compiled for the first call's values ^[12]. That plan has to stay valid whenever any parameter is NULL. The post says that requirement pushes the optimizer towards scans ^[12]. Ten optional filters allow up to 1,024 on/off combinations ^[1]. The post points to Erland Sommarskog's Dynamic Search Conditions in T-SQL for the full set of options ^[18]. If the composed builder emits only the predicates a request uses, the same one-plan-per-text rule gives each filter shape its own plan ^[12].

The test setup is the best engineering in the post. It runs both versions on one schema against a real SQL Server 2025 container ^[3][4], on Spring JDBC with `NamedParameterJdbcTemplate` and records, no JPA ^[4]. That matters because the plan-cache argument is about one engine's behaviour. A matching-rows result says the demo's fixtures agree. It carries to another codebase only if that codebase's fixtures exercise every role and every delegation edge it has.

Two more findings point the same way. The legacy `LEFT JOIN`s multiply rows, and `DISTINCT` hides that instead of avoiding it ^[16]. The author email is hidden in the row mapper after it has already been fetched ^[15]. A visibility strategy that also chose the projection would keep the column in the database for non-admins.

In my view the strategy split is right for a screen with five roles and dated delegations ^[5][6]. A screen with two roles and three filters is cheaper to own as one method.