Read a Store attribute through a typed adapter
Resolve the current Store context once, read attributes through a small boundary, and parse the expected code into a typed value. Do not spread portal IDs or string lookups through application code.
In this guide
Keep the platform seam narrow
A Store setting is context-dependent. The caller should ask for SupportLabel, while one adapter obtains the current Store identifier and returns attribute rows. That keeps the rest of the application independent of service-model shape and makes missing data an explicit result.
StoreSettings.cs csharp
using System;
using System.Collections.Generic;
using System.Linq;
public sealed class AttributeRow
{
public string Code { get; set; }
public string Value { get; set; }
}
public interface IStoreAttributeSource
{
IReadOnlyList<AttributeRow> ReadForCurrentStore();
}
public sealed class StoreSettings
{
private readonly IStoreAttributeSource source;
public StoreSettings(IStoreAttributeSource source)
{
if (source == null) throw new ArgumentNullException(nameof(source));
this.source = source;
}
// null means absent. Dependency failures are not converted to absence.
public string SupportLabel()
{
var row = source.ReadForCurrentStore().SingleOrDefault(x =>
string.Equals(x.Code, "GcgSupportLabel", StringComparison.OrdinalIgnoreCase));
return row == null || row.Value == null ? null : row.Value.Trim();
}
public int LeadDaysOrDefault(int fallback)
{
if (fallback < 0) throw new ArgumentOutOfRangeException(nameof(fallback));
var row = source.ReadForCurrentStore().SingleOrDefault(x =>
string.Equals(x.Code, "LeadDays", StringComparison.OrdinalIgnoreCase));
int days;
return row != null && int.TryParse(row.Value, out days) && days >= 0
? days : fallback;
}
}Choose missing-value behavior
A display label can be optional and return null. A value that controls checkout, pricing, or security should usually fail closed or be validated at configuration time. Do not turn a failed lookup into a hardcoded Store ID or a default account.
Verify context and duplicates
Use a test double with two Store contexts. Confirm that each context returns its own value, a missing value takes the documented path, and duplicate GcgSupportLabel rows throw rather than silently choosing one. Then add an integration check against the declared patch to prove the adapter's platform call and locale behavior.
Make the adapter own platform details
Implement IStoreAttributeSource in one infrastructure class. That class should obtain the Store or portal identifier from the authenticated request context, call the supported global-attribute service for the exact patch, and map only Code and Value into AttributeRow. It must not accept a Store ID from an arbitrary query string, and it should not log raw values when those values may contain configuration or contact information.
Cache only when the value has a clear invalidation story. Include the Store context and locale when either changes the returned row. Start without caching if the setting is edited infrequently but correctness matters more than a small lookup cost. A dedicated adapter also gives a later migration one place to update when platform service models or context APIs change.
References and further reading
Bring your next engineering question.
Need help reducing risky configuration coupling?
Independent guidance from GCG. Znode is a trademark of its owner. Examples use fictional data and are not official platform documentation. Suggest a correction.