È troppo lavoro da fare per un Gateway?

In generale, una classe gateway dovrebbe tradurre dall'interfaccia che hai nell'interfaccia desiderata. Se l'interfaccia che desideri è un semplice controllo di presenza, scrivilo in ogni modo.

Vorrei solo avvertirti quando i requisiti cambiano e l'applicazione cresce, per non avere paura di rivalutare questa decisione. Se la classe del gateway inizia a sembrare troppo grande, o come se stesse costringendo troppi livelli di astrazione insieme, dividerli in uno che recupera l'elenco e uno che filtra / cerca nell'elenco. Anche se hai solo una classe, queste dovrebbero essere almeno funzioni separate.

Torniamo ai solidi vecchi principi SOLID. Attualmente, il tuo Gateway è:

• Fornire integrazione con l'interfaccia Web AND
• Verifica di un articolo nell'inventario degli utenti.

Hai rotto il principio di Responsabilità Unica :) È terribile? No, non proprio, ma, credimi, è molto più facile correggerlo ora, mentre non hai un'applicazione di grandi dimensioni invece di correggere cose del genere più tardi.

Quindi, lo farei in questo modo:

// Inventory service.
public class InventoryService
{
    private IWebInventoryGateway _gateway;

    // Injecting a dependency here to decouple classes
    public InventoryService(IWebInventoryGateway gateway)
    {

    }

    // Method that does one an only thing! Checking if the item is in the inventory.
    public bool ContainsItems(string item, int playerId) {
        var inventory = _gateway.GetInventory(playerId);

        // do the list checking here...

        return true;
    }
}

// Gateway interface so you could swap your gateways without affecting any other classes. Decoupling here.
public interface IWebInventoryGateway
{
    IEnumerable<string> GetInventory(int playerId);
}