ASP.NET Core注入TeamRepository无法解析System.String服务如何解决

问题根因 #

你向DI容器注册了ITeam对应的实现类TeamRepository，但TeamRepository的构造函数要求传入string类型的连接字符串参数，.NET默认DI容器无法自动解析未注册的string类型参数，因此触发构造失败的报错。
此外你当前的服务层ITeamService已经手动实例化了TeamRepository，完全不需要将ITeam/TeamRepository注册到DI，该注册属于冗余操作。

解决方案 #

方案1（最简适配现有代码） #

直接删除Startup中冗余的仓储注册代码即可：

// 删除这行代码
services.AddTransient<ITeam, TeamRepository>();

删除后服务层会继续使用手动实例化的仓储，DI不会再尝试构造TeamRepository，报错即可解决。

方案2（规范DI依赖注入逻辑） #

如果你希望所有依赖都由DI容器管理，避免手动new实例，可以按以下步骤修改：

1. 修改TeamRepository构造函数，改为注入配置项，不再直接接收字符串参数：

public TeamRepository(IOptions<DataConnection> options)
    : base(options.Value.DefaultConnection)
{
}

2. 修改服务层实现，改为注入ITeam接口，不再手动实例化仓储（顺便建议修改类名，类名开头加I不符合C#命名规范，容易和接口混淆）：

// 类名建议修改为TeamService
public class TeamService : ITeamRepoService
{
    private readonly ITeam _repository;

    public TeamService(ITeam repository)
    {
        _repository = repository;
    }

    public List<TeamDetails> GetAllTeams()
    {
        return _repository.GetAllTeams();
    }
}

3. 同步修改Startup的服务注册：

services.Configure<DataConnection>(Configuration.GetSection("AppDbConnection"));
services.AddTransient<ITeamRepoService, TeamService>();
services.AddTransient<ITeam, TeamRepository>();

额外潜在问题修复建议 #

• 基类AdoRepository中的SqlConnection对象设置为static会导致多线程并发请求时出现连接占用冲突，建议去掉static修饰符，每次数据库操作新建连接即可，ADO.NET自带连接池不会有性能问题。
• PopulateRecord方法中TeamId = Convert.ToInt32(reader.GetString(0))写法存在隐患，如果数据库中TeamId是int类型，直接使用reader.GetInt32(0)读取即可，先转字符串再转int容易触发格式转换异常。

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