Para mim, se você usa uma única linha ou EAV, depende de como você deseja consumi-los.
O poder do EAV é que novos dados possam ser adicionados sem alterações na estrutura. Isso significa que, se você deseja um novo valor de configuração, basta adicioná-lo à tabela e retirá-lo onde deseja no código, e não precisa adicionar um novo campo ao domínio, esquema, mapeamento, consultas DAL etc.
Sua falha é que ele possui apenas a estrutura mais simples, exigindo que você lide com os dados de maneira pessimista. Todo uso de qualquer valor de configuração deve esperar que o valor não esteja presente ou não esteja no formato adequado e se comporte de acordo quando não estiver. Um valor de configuração pode não ser analisável para um double, int, ou char. Pode ser nulo. pode não haver linha para o valor. As maneiras de contornar isso geralmente exigem que exista um único valor "padrão" válido para todos os valores de configuração de um tipo de código em particular ( extremamente raro; mais frequentemente, o valor padrão é tão problemático para consumir código quanto nenhum), ou mantenha um dicionário codificado de valores padrão (que deve mudar toda vez que uma nova coluna é adicionada, tornando a principal vantagem do armazenamento EAV bastante discutível).
Uma única linha larga é praticamente o oposto. Você o mapeia para uma única instância de um objeto Configuration com um campo / propriedade para cada valor de configuração existente. Você sabe exatamente que tipo esses valores devem ser no momento da compilação e "falha rapidamente" no DAL se uma coluna de configuração não existir ou não tiver um valor do tipo adequado, oferecendo um lugar para capturar exceções com base em problemas de recuperação / hidratação da configuração.
A principal desvantagem é que uma mudança estrutural é necessária para cada novo valor; nova coluna de banco de dados, nova coluna no DAL (o mapeamento ou as consultas SQL / SPs), nova coluna de domínio, tudo necessário para testar adequadamente o uso.
A situação adequada para usar qualquer um desses é a situação na qual as desvantagens são mitigadas. Para mim, a maioria das situações de codificação de configuração exigiu uma implementação de linha única. Isso ocorre principalmente porque se você está introduzindo um valor de configuração totalmente novo que governa o comportamento de alguma parte do seu programa, você já precisa alterar o código para usar o novo valor de configuração; por que não aparecer no objeto de configuração e adicionar o valor a ser usado?
Em resumo, um esquema EAV para armazenar configuração realmente não resolve o problema que pretende resolver, e a maioria das soluções alternativas para os problemas apresentados viola o DRY.