将Dapper.Contrib用作实体类时为何失败？桌面应用继承式设计疑问

我来帮你梳理下之前踩过的坑，再聊聊你这个继承式设计的可行性——

一、之前使用Dapper.Contrib实体类失败的常见原因 #

这些都是我见过很多开发者踩过的坑，你可以对照排查：

• 特性使用出错：要么是没加[Table]指定数据库表名（Dapper.Contrib默认会用实体类名当表名，要是表名不一样就会报错），要么是[Key]标记错了字段（比如标记了非自增主键，或者主键类型和数据库不匹配）；还有可能是引错了命名空间，Dapper.Contrib的特性在Dapper.Contrib.Extensions下，别和EF之类的ORM特性搞混。
• 实体与表结构不匹配：比如字段大小写不一致（像PostgreSQL这种区分大小写的数据库，实体属性名和表字段名大小写不对就会映射失败），或者字段类型不兼容（比如数据库存的是datetime，实体用了DateTimeOffset）；另外，要是实体有数据库里没有的公共属性，又没加[Computed]或[Write(false)]标记，插入时会因为数据库找不到对应字段报错。
• 连接/事务问题：比如调用CRUD方法时数据库连接没打开，或者在事务场景下没把事务对象传给Dapper.Contrib的方法；还有可能是连接字符串配置错了，根本连不上数据库。
• 版本兼容问题：Dapper和Dapper.Contrib的版本要匹配，比如Dapper升级到2.x后，旧版本的Contrib可能会出现API不兼容的情况（比如Insert方法的返回值类型，旧版可能返回bool，新版返回long）。
• 实体属性访问权限问题：要是实体的属性不是public的，Dapper.Contrib没法通过反射读取/写入这些属性，自然会映射失败。

二、继承式DB抽象类设计的可行性分析 #

这个设计是可行的，但有明显的优缺点，你得结合自己的场景权衡：

优点 #

• 代码复用性拉满：把Insert、Update、Delete这些通用CRUD逻辑都封装在抽象类里，所有业务实体不用重复写这些代码，省了不少事。
• 使用起来很直观：业务实体直接继承DB类，就能直接调用Insert()这类方法，像你示例里那样，写代码的时候不用再单独搞个数据访问层，上手快。
• 连接管理统一：通过ConFactory.GetConnection()统一获取数据库连接，后续要是想改连接逻辑（比如换数据库、加连接池配置），只需要改这个工厂类就行，不用改所有实体。

潜在问题与注意事项 #

• 违反单一职责原则：实体类本来应该只负责承载业务数据，现在继承了DB类，同时拥有了数据访问能力，把领域模型和数据访问逻辑耦合在一起了。后续业务复杂了，实体类会变得臃肿，不好维护。
• 灵活性不够：要是某个实体需要特殊的CRUD逻辑（比如插入前要做复杂校验，或者需要在事务中执行），虽然可以重写抽象类的虚方法，但如果很多实体都要这么搞，反而会增加复杂度；另外，Dapper.Contrib默认会插入所有属性，要是有些实体需要忽略某些字段，要么加特性，要么重写方法，有点麻烦。
• IDisposable的坑：抽象类实现了IDisposable，业务实体继承后，要是实体本身有需要释放的资源，得正确实现Dispose模式（比如重写Dispose(bool disposing)），否则容易出现资源泄漏。你示例里的DB类现在Dispose是空实现还好，但后续要是加了连接相关的资源，一定要注意正确释放。
• 测试麻烦：因为实体和数据访问逻辑耦合在一起，单元测试的时候没法单独测实体的业务逻辑，必须依赖数据库，测试效率低，也不好模拟异常场景。

小建议 #

如果想兼顾代码复用和低耦合，不如把CRUD逻辑放在单独的泛型仓储类里（比如GenericRepository<T>），实体类只负责存数据，这样更符合设计原则；要是坚持用继承式设计，记得把DB类的CRUD方法都设为virtual，方便子类重写，同时把IDisposable的实现做扎实，也可以考虑给方法加参数支持传入事务，提升灵活性。

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