Neutral Culture

Neutral Culture ou Cultura Neutra é o termo utilizado para referenciar uma cultura específica, sem ter uma região ou um país vinculado. Quando estamos trabalhando com globalização de aplicações .NET (seja ela Windows ou Web), é comum criarmos arquivos de recursos (*.resx) que representam uma cultura juntamente com uma região, como por exemplo: “pt-BR”, “pt-PT”, “en-US”, “en-NZ”, etc.

Uma cultura é considerada neutra quando referenciamos apenas a cultura, como por exemplo: “pt” ou “en”. Com isso, independentemente da região (Brasil ou Portugal), podemos ter uma única versão, ou seja, portugues é portugues no Brasil e em Portugal; já noutro exemplo (Estados Unidos ou Nova Zelandia), ingles é ingles nos Estados Unidos e na Nova Zelandia.

É importante dizer que a cultura neutra pode ser utilizada apenas para a globalização da interface (arquivos *.resx). Isso se deve ao fato de que para formatar números, datas, efetuar parsing, etc., é necessário determinar os separadores, convenções, moedas, etc. Essas informações são características de uma região específica e que, a cultura neutra não disponibiliza. Para saber se a instancia da classe CultureInfo está ou não armazenando uma cultura neutra, basta recorrer a propriedade IsNeutralCulture, que retorna uma valor booleano indicando isso.

CultureInfo ci = CultureInfo.GetCultureInfo(“en”);
Console.WriteLine(ci.IsNeutralCulture); //Retornará True

Compartilhando tipos entre o serviço e o cliente

Uma questão que sempre é levantada quando falamos de contratos de serviços WCF, refere-se ao compartilhamento dos tipos que são expostos pelo documento WSDL. Para retornar e/ou receber uma instancia de uma classe customizada, basta referenciarmos este tipo em um contrato que, automaticamente, ele já será embutido no documento WSDL. Com isso, ao referenciar o serviço no cliente, uma representação desta classe será criada para que seja possível enviar e/ou receber uma instancia deste objeto complexo.

Durante a referencia (independentemente de qual artefato é utilizado para realizá-la (através da IDE ou utilitário svcutil.exe)), ele olhará para o projeto onde o serviço está sendo referenciado, para determinar se o tipo que o serviço expõe/retorna já existe dentro do mesmo. Caso ele não exista, automaticamente uma classe será criada para representá-la que, obviamente, será baseada no documento WSDL. Essa técnica fornece um baixo acoplamento, assim como já era o caso dos ASP.NET Web Services (ASMX).

Como sabemos, a serialização apenas persiste o estado de um objeto. Isso quer dizer que possíveis métodos e/ou atributos especiais não são propagados através deste processo. Há casos em que se quer compartilhar não somente o estado de um objeto, mas também outras funcionalidades que o mesmo forneça, e que está além das capacidades do processo de serialização.

É neste cenário que o compartilhamento de tipos entra em cena. Isso deve mudar ligeiramente a estrutura das aplicações, ou seja, o tipo a ser compartilhado entre o serviço e o cliente deverá ser isolado em um Assembly (DLL), referenciado pelas duas aplicações. O contrato do serviço agora passará a receber e enviar instancias da classe que está neste Assembly compartilhado e com isso, ao invés de criar uma nova classe para representar o objeto, a IDE (ou o utilitário svcutil.exe) irá fazer o uso deste tipo que, além do estado das propriedades que foram fornecidas pelo serviço, temos todas as possíveis funcionalidades que este objeto fornece. Ao contrário do que vimos acima, esta técnica traz um forte acoplamento entre os envolvidos, bem como já acontecia com o .NET Remoting, obrigando as “duas pontas” serem WCF.

A vantagem do compartilhamento é que a cada nova mudança no contrato, ou melhor, nas propriedades do objeto, não há necessidade de atualizar a referencia do serviço para que ele sincronize o objeto local com o objeto exposto pelo documento WSDL. Se todos os projetos estão dentro da mesma solução, basta uma simples compilação e tudo já estará funcionando. Esse comportamento melhora consideravelmente a produtividade e conveniencia durante o desenvolvimento do serviço e do cliente, enquanto o ponto negativo gira em torno da interoperabilidade e do acoplamento que se tem entre os participantes.