C#一对多关系下Bank与BankBranch对象模型选型咨询

我正在设计用于存储客户及相关信息的对象，现有如下对象结构：

• Customer（父对象）
• Company（Customer的子类）
• BankBranch（Customer的子类）
• Bank

数据库表结构如下：
Bank表

• Bank Id（主键）
• Bank Name
  BankBranch表
• Branch Id（主键）
• Bank Id（外键）
• Branch Details

Bank与BankBranch为一对多关系（一个Bank包含多个BankBranch），业务场景为：大多数情况下，会将BankBranch作为客户来记录文件；同时系统设有银行管理页面，用户可查看Bank列表，选中单个Bank时需展示其下属的BankBranch列表。

现纠结以下三种模型设计方案，请问应选择哪一种：

方案1：Bank仅包含Id和Name，BankBranch包含Bank属性 #

public class Bank {
    int bankId {get;set}
    string bankNme {get;set;}
}
public class BankBranch : Customer {
    Bank bank {get;set;}
    string branchDetails {get;set;}
}

方案2：Bank包含BankBranch列表，BankBranch仅包含分支详情 #

class Bank{
    int bankId {get;set}
    string bankNme {get;set;}
    List<BankBranch> branchList {get;set;}
}
public class BankBranch : Customer {
    string branchDetails {get;set;}
}

方案3：Bank包含BankBranch列表，BankBranch包含Bank属性 #

public class Bank{
    int bankId {get;set}
    string bankNme {get;set;}
    List<BankBranch> branchList {get;set;}
}
public class BankBranch : Customer {
    Bank bank {get;set;}
    string branchDetails {get;set;}
}

方案选择建议 #

选方案3，理由如下：

1. 匹配双向业务需求：日常用BankBranch做客户记录时，能直接通过BankBranch.Bank拿到所属银行信息；银行管理页面查看分支时，Bank.branchList直接提供关联的分支列表，两头的业务场景都能覆盖，不用额外写查询逻辑。
2. 贴合数据库关联逻辑：数据库里BankBranch靠外键关联Bank，双向导航属性完整还原了这种一对多关系，不管从哪一端发起关联操作都很顺畅。
3. 扩展性更强：后续如果新增业务，比如统计某银行的客户分支数量、查看分支所属银行的详细信息，现有模型直接支持，不用修改结构。

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