C#创建列表最佳实践：List<string>与自定义强类型列表选型对比

问题描述 #

创建列表的最佳实现方式是哪一种？
第一种写法是直接创建字符串类型列表：

List<string> Person = new List<string>() {"James", "Harry", "Jonson"};

还是使用自定义强类型的写法：

List<Person> Person = new List<Person>() {new Person("James"), new Person("Harry"), new Person("Jonson")};

对应自定义类的代码如下：

class Person {
    
    public string Name;
    
    public Person(string newName) {
        this.Name = newName;
    }
}

核心疑问：实际开发中，创建业务场景对应的自定义强类型列表是否可读性、合理性更优，还是在当前示例场景下直接创建string类型列表即可？ #

解答 #

不存在适用于所有场景的“最优写法”，选型完全取决于业务需求，核心判断依据是列表承载的数据后续是否需要扩展属性、是否会参与业务逻辑流转：

• 如果你只是临时存储若干纯姓名字符串，后续不会给这些条目追加年龄、工号、所属部门等其他属性，也不会围绕单个条目做除读取姓名外的逻辑处理，直接用List<string>就足够。这种写法代码量小，没有额外的类型定义开销，简单场景下可读性更高，没必要为了追求“强类型”做无意义的冗余封装。
• 只要这个列表用于正式业务流转，比如后续需要给人员追加身份信息、权限标记、关联数据，或者需要对单个人员做校验、排序、持久化存储等操作，一定要用自定义Person类的强类型列表。强类型方案的优势会在业务迭代过程中充分体现：
  • 编译期就能做类型检查，能避免传参时字段顺序错乱、类型不匹配的低级错误
  • 后续扩展属性只需要修改Person类定义即可，不需要全局重构所有存人名的字符串逻辑
  • 业务语义更明确，其他开发者看到List<Person>立刻能知道这是人员实体集合，看到List<string>还需要翻上下文确认字符串存的是人名、工号还是其他无关内容
    另外提一个示例代码里的小规范问题：集合类型的变量不要用单数类名Person命名，改成复数形式People或者Persons更符合C#的命名惯例，也能避免和类名重名造成的识别混淆。

内容的提问来源于stack exchange，提问作者Tidra