モデルに「FullName」や「FormattedPhoneNumber」などのゲッターを配置するのは「パターン臭」ですか？

私はASP.NET MVCアプリに取り組んでおり、便利で便利なゲッターをモデル/エンティティクラスに入れる習慣を身につけています。

例えば：

public class Member
{
    public int Id { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public string PhoneNumber { get; set; }

    public string FullName
    {
        get { return FirstName + " " + LastName; }
    }

    public string FormattedPhoneNumber
    {
        get { return "(" + PhoneNumber.Substring(0, 3) + ") " + PhoneNumber.Substring(3, 3) + "-" + PhoneNumber.Substring(6); }
    }
}

FullNameとFormattedPhoneNumberゲッターについて人々が考えるのだろうか。

アプリ全体で標準化されたデータ形式を非常に簡単に作成でき、繰り返しコードを大量に保存するように見えますが、データ形式はモデルからビューモデルへのマッピングで処理されるべきものであると断言できます。

実際、私は元々、これらのデータ形式をマッピングを行うサービスレイヤーに適用していましたが、フォーマッタを絶えず書き、それをさまざまな場所に適用しなければならないのは負担になりました。例えば、私はほとんどのビューで「フルネーム」を使用model.FullName = MappingUtilities.GetFullName(entity.FirstName, entity.LastName);し、model.FullName = entity.FullNameあちこちに何かを入力しなければならないことは、単に入力するよりもはるかにエレガントではないように見えました（または、AutoMapperのようなものを使用すると、何も入力しない可能性があります）。

それで、データのフォーマットに関してはどこで線を引きますか。モデルでデータのフォーマットを行うのは「大丈夫」ですか、それとも「パターンの匂い」ですか？

注：私のモデルにはHTMLが含まれていません。そのためにhtmlヘルパーを使用します。データ（特に頻繁に使用されるデータ）のフォーマットまたは結合について厳密に説明しています。

あなたの例では、FullName（あなたが与えたすべての理由で）ゲッターは好きですが、FormattedPhoneNumberゲッターは好きではありません。その理由は次のとおりです。それは（あなたが国際電話番号などを持っていたら）、あなたはの方法で電話番号をフォーマットするためのロジックを配置する場合は簡単ということはおそらくないMember、チャンスはあなたがリファクタリング（またはコピー＆ペーストにする必要がありますされているcaughます1回）以下のためにフォーマットされた電話番号を必要とするInstitution、Vendorあまりになど。

編集：IMO PhoneNumberはFormattedゲッターを持つクラスを持つ方が良いでしょう。

コードを書くときに考慮する必要があること：それは正しいですか？読みやすいですか？効率的ですか？保守可能ですか？@btillyが述べたように、カルチャ固有の書式設定のために維持できないと主張しますが、質問はそれより一般的であるようです。

このようなアクセサを使用すると、コードが読みやすくなり、使用方法によってはコードの他の部分がよりきれいになる場合があります。私の意見では、それはまったく臭いがしません。あなたが印刷したいかもしれないあらゆる種類の文字列のフォーマットアクセサを持っていると、臭いがし始めます（public string FirstLastName; public string FullName; public string FullNameWithMiddleInitial; public string PhoneNumberWithAreaCode; public string PhoneNumberWithoutAreaCode; public string PhoneNumberWithCountryCode;、など）

別の言い方をすれば、パターンを使用しても、コードに「パターンの匂い」が自動的に生じるわけではありません。その属性を獲得したい場合は、悪用する必要があります。

単一の責任原則を破ります。電話番号クラスなどを作成してみませんか？

あなたの例では、特定の形式を使用するのにあまりにも大したことではないと思います。1つまたは2つで、アプリケーションのすべての部分で同じ形式が使用されます。

その決定が崩れ始めるのは、同じデータが異なるフォーマットを必要とするいくつかの異なる場所に行くときです。

それが起こった場合、Memberクラスを次の場所に引き戻したいと思います。

public class Member
{
    public int Id { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public string PhoneNumber { get; set; }  
}

そして、ターゲットごとに異なるアダプターを実行します。たとえば、情報がCSV形式で必要だったとします。

public static class CSVMemberAdapter
{
    public static string ToCSV(this Member mbr)
    {
         return mbr.Id + "," + mbr.LastName + "," + mbr.FirstName, "," mbr.PhoneNumber;
    }
}

文字列にコンマなどが含まれないようにデータをサニタイズしたと常に仮定します。

アダプターは拡張メソッドである必要はありませんが、このメイクアップケースでは収まるようです。