3

ローカリゼーションをサポートするドメイン モデルを作成しようとしています。以前に尋ねられたいくつかのSOの質問を見てきましたが、提案された解決策があまり好きではありませんでした. たとえば、この質問では、ローカライズされたデータをサポートする必要があるエンティティごとに追加のエンティティを作成するのはやり過ぎだと思います。すべてのエンティティのローカライズされたデータを、ローカライズされたデータを保持することのみを目的とする 1 つのエンティティに配置したいと考えています。

私の提案する解決策は次のとおりです。

  1. LocalizedEntityローカリゼーションをサポートする必要があるすべてのエンティティが継承するクラスを作成します。

  2. LocalizedDataカルチャごとに実際のローカライズされた値を基本的に保持するエンティティを作成します。

アップデート：

public class LocalizedEntity
{
    public String Code { get; set; }
}

public enum ResourceType
{
    CityName,
    CityDescription,
    StreetName,
    AreaName
    //others...
}

public class LocalizedData
{
    public Int32 Id { get; set; }
    public String Code { get; set; }
    public ResourceType Type { get; set; }
    public Int32 CultureId { get; set; }
    public String Value { get; set; }
}

public class City : LocalizedEntity
{
    public Int32 Id { get; set; }
    public virtual ICollection<Area> Areas { get; set; }
    //others
}

したがって、ビジネス層はローカライズされたエンティティを取得し、 および によってエンティティからローカライズされた値を取得しLocalizedDataます。そしてもちろん、データベースへの多くの往復を避けるために、何らかのキャッシングが適切な場合があります。CodeResourceType

あなたの考え？

4

1 に答える 1

4

モデル化しているのは、EAV (entity-attribute-value) ストレージです。まもなく、「リソース タイプ」列挙型が管理不能な状態にオーバーフローします。侮辱に加えて、それはデータベース構造の点でかなり効果的ではありません。

コードの可読性のデータベースの使用に関して引き続き保守可能なローカライズが必要な場合は、プロパティではなくエンティティをローカライズする必要があります。つまり、データベースの各行は、エンティティ ID、言語 ID、およびそのエンティティのデータをその言語で保持する必要があります。

于 2012-09-15T11:24:12.323 に答える