มันเป็น "รูปแบบกลิ่น" ที่จะนำตัวแบบเช่น "FullName" หรือ "FormattedPhoneNumber" ในรุ่นของคุณหรือไม่?

ฉันกำลังทำงานกับแอพ ASP.NET MVC และฉันเริ่มติดนิสัยในการวางสิ่งที่ดูเหมือนว่า getters ที่เป็นประโยชน์และสะดวกในคลาส / โมเดลเอนทิตีของฉัน

ตัวอย่างเช่น:

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และFormattedPhoneNumbergetters

พวกเขาทำให้ง่ายต่อการสร้างรูปแบบข้อมูลที่เป็นมาตรฐานทั่วทั้งแอพและดูเหมือนว่าจะบันทึกรหัสซ้ำจำนวนมาก แต่อาจเป็นที่ถกเถียงกันอยู่ว่ารูปแบบข้อมูลนั้นเป็นสิ่งที่ควรจัดการในการทำแผนที่จากแบบจำลองไปยังแบบจำลอง

ที่จริงแล้วฉันเดิมใช้รูปแบบข้อมูลเหล่านี้ในชั้นบริการของฉันที่ฉันทำแผนที่ของฉัน แต่มันก็กลายเป็นภาระที่ต้องเขียน formatters อย่างต่อเนื่องแล้วนำไปใช้ในหลาย ๆ ที่ เช่นฉันใช้ "ชื่อเต็ม" ในมุมมองส่วนใหญ่และต้องพิมพ์บางสิ่งบางอย่างเหมือนmodel.FullName = MappingUtilities.GetFullName(entity.FirstName, entity.LastName);ทั่วสถานที่ดูเหมือนจะดูสง่างามกว่าการพิมพ์เพียงเล็กน้อยmodel.FullName = entity.FullName(หรือถ้าคุณใช้บางอย่างเช่น AutoMapper อาจไม่พิมพ์อะไรเลย)

ดังนั้นคุณจะวาดเส้นที่ไหนเมื่อมันมาถึงการจัดรูปแบบข้อมูล "โอเค" ในการจัดรูปแบบข้อมูลในโมเดลของคุณหรือเป็น "กลิ่นของรูปแบบ" หรือไม่?

หมายเหตุ: ฉันไม่มี html ใด ๆ ในแบบจำลองของฉัน ฉันใช้ตัวช่วย html เพื่อสิ่งนั้น ฉันกำลังพูดถึงการจัดรูปแบบหรือการรวมข้อมูลอย่างเคร่งครัด (และโดยเฉพาะอย่างยิ่งข้อมูลที่ใช้บ่อย)

ในตัวอย่างของคุณฉันชอบFullNameทะเยอทะยาน (ด้วยเหตุผลทั้งหมดที่คุณให้) แต่ฉันไม่ชอบฟอร์แมต เหตุผลก็คือ: มันอาจไม่ใช่เรื่องง่าย (เมื่อคุณมีหมายเลขโทรศัพท์ระหว่างประเทศเป็นต้น) และถ้าคุณวางตรรกะในการจัดรูปแบบหมายเลขโทรศัพท์ด้วยวิธีการMemberโอกาสที่คุณจะต้อง refactor (หรือคัดลอกวางcaugh ) เมื่อคุณ จำเป็นต้องมีการจัดรูปแบบหมายเลขโทรศัพท์สำหรับInstitution, Vendorฯลฯ เกินไป

แก้ไข: IMO มันจะดีกว่าที่จะมีPhoneNumberชั้นเรียนที่มีFormattedทะเยอทะยาน

สิ่งที่คุณต้องพิจารณาเมื่อเขียนรหัส: ถูกต้องหรือไม่ มันอ่านได้หรือไม่ มันมีประสิทธิภาพหรือไม่ มันสามารถบำรุงรักษาได้หรือไม่? ฉันจะโต้แย้งอย่างที่ @btilly พูดถึงว่ามันไม่สามารถบำรุงรักษาได้เนื่องจากการจัดรูปแบบเฉพาะวัฒนธรรม แต่คำถามดูเหมือนจะเป็นเรื่องทั่วไปมากกว่านั้น

การใช้ accessors เช่นนี้ทำให้โค้ดของคุณอ่านง่ายขึ้นและขึ้นอยู่กับว่าคุณใช้มันอย่างไรอาจทำให้ส่วนอื่น ๆ ของโค้ดของคุณสะอาดขึ้น ในความคิดของฉันมันไม่ได้มีกลิ่นเลย มันจะเริ่มมีกลิ่นถ้าคุณมีการจัดรูปแบบ accessors สำหรับสตริงชนิดใด ๆ ที่คุณอาจต้องการพิมพ์ ( public string FirstLastName; public string FullName; public string FullNameWithMiddleInitial; public string PhoneNumberWithAreaCode; public string PhoneNumberWithoutAreaCode; public string PhoneNumberWithCountryCode;ฯลฯ )

หรืออีกวิธีหนึ่งการใช้รูปแบบไม่ทำให้รหัสของคุณมี "รูปแบบกลิ่น" โดยอัตโนมัติ คุณต้องใช้มันหากคุณต้องการที่จะได้รับคุณลักษณะนั้น

แบ่งหลักการความรับผิดชอบเดียว ทำไมไม่สร้างคลาสหมายเลขโทรศัพท์ ฯลฯ ...

สำหรับตัวอย่างของคุณฉันไม่เห็นข้อตกลงที่จะใช้รูปแบบที่เฉพาะเจาะจงมากเกินไป มันเป็นหนึ่งหรือสองส่วนและทุกส่วนของแอปพลิเคชันใช้รูปแบบเดียวกัน

ไหนว่าการตัดสินใจจะเริ่มต้นที่จะทำลายลงคือเมื่อคุณมีข้อมูลเดียวกันจะไปยังสถานที่ที่แตกต่างกันกำหนดรูปแบบที่แตกต่างกัน

หากสิ่งนั้นเกิดขึ้นฉันจะถูกล่อลวงให้ดึง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;
    }
}

สมมติว่าคุณได้ทำการล้างข้อมูลให้เสมอเพื่อไม่ให้มีเครื่องหมายจุลภาค ฯลฯ อยู่ในสตริง

อะแดปเตอร์ไม่จำเป็นต้องเป็นวิธีการขยาย แต่สำหรับกรณีที่เชื่อว่ามันดูเหมือนจะพอดี