ASP.NET MVC项目：数据库层转换Dataset结果是否可行及最佳实践

问题背景 #

我正在开发一个采用N层架构的C# ASP.NET MVC项目，数据库项目中的EmployeeRepo类包含多个函数，每个函数从事务中得到的原生结果为Dataset，会根据需求进行转换。当前的返回类型包括：

• Dataset（包含一个或多个表）
• DataTable
• int
• bool
• Object（单个员工对象）
• List<Object>（员工对象列表）

现咨询以下两种方案哪种更优，是否有遵循的标准：

1. 直接返回原生结果，不在数据库层转换，转换仅在其他层进行。
2. 在数据库层转换结果后再返回。

方案分析与对比 #

两种方案均具备可行性，核心差异在于职责划分与维护成本，结合N层架构的通用设计原则分析如下：

方案1：数据库层返回原生Dataset，转换在其他层进行 #

优势

• 职责单一：数据库层仅负责数据的读写操作，不承担业务模型转换职责，符合单一职责原则，边界清晰。
• 灵活性强：同一原生Dataset可在不同业务场景下转换为不同模型，避免数据库层与业务逻辑绑定。
• 低耦合：业务模型变更时，无需修改数据库层代码，仅需调整上层转换逻辑。

劣势

• 潜在重复代码：若多个上层模块需要对同一Dataset执行相同转换，易出现逻辑重复，需额外抽离转换工具类解决。
• 上层复杂度提升：业务层或表现层需处理Dataset解析，增加了上层代码量。

方案2：数据库层转换后返回目标类型 #

优势

• 上层代码简洁：业务层直接获取可用的模型或基础类型，无需处理Dataset解析，减少冗余代码。
• 转换逻辑集中：所有Dataset到业务模型的转换统一在数据库层维护，避免重复实现。
• 类型安全：编译阶段即可发现类型转换错误，降低运行时异常概率。

劣势

• 职责模糊：数据库层同时承担数据访问与模型转换职责，违反单一职责原则，业务模型变更时需同步修改数据库层。
• 灵活性不足：若后续有新场景需要使用原生Dataset，需修改现有Repo方法或新增接口，增加维护成本。

遵循的标准与建议 #

1. 严格遵循架构职责划分时选方案1：如果项目严格执行N层架构的职责边界（数据访问层负责数据交互，业务逻辑层负责业务处理，表现层负责展示），建议将转换逻辑放在业务逻辑层，或抽离独立的ModelMapper层统一处理转换，保证各层职责清晰。
2. 追求快速开发且业务稳定时选方案2：若业务模型变动频率低，且希望上层代码更简洁，可选择在数据库层转换，但需在数据库层内拆分数据访问与转换逻辑（比如用私有转换方法或独立转换类），避免代码耦合。
3. 特殊场景灵活处理：对于返回int/bool这类简单类型的场景，直接在数据库层转换后返回更合理；若上层确实需要直接操作数据集，保留Dataset/DataTable的原生返回即可。

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