在服务类上具有状态代表属性是一种好的设计吗？

Question

我有一个带有服务类的应用程序，它从数据库中检索数据库元数据并将其返回给调用类。

要连接到数据库，服务类方法接受一个详细说明连接凭据的参数。

我正在考虑将凭据存储在服务类中的更改。造成这种情况的原因之一是调用类（例如，负责比较不同服务器上的模式）可能连接到多个不同的数据库/服务器，因此调用类基本上会有这些服务类的集合，而不是而不是连接凭据的集合（例如，以下示例中的 IConnectionInfo）。

我可能想在应用程序中做的另一件事是为不同类型的 RDBMS（例如 SQL Server、Oracle 等）实现此服务类（以下示例中为 IDatabaseService），这似乎就像让它保持开放的最佳方式（从服务返回的信息将非常通用，适用于所有受支持的 RDBMS 类型）。

服务类的示例代码：

public class DatabaseService : IDatabaseService
{
    private readonly IConnectionInfo ConnectionInfo;
    
    public bool IsConnected; // INotifyPropertyChanged
    
    public string ServerName => IConnectionInfo.ServerName;
    public string DatabaseName => IConnectionInfo.DatabaseName;
    
    public DatabaseService(IConnectionInfo connectionInfo)
    {
        ConnectionInfo = connectionInfo;
    }
    
    public IEnumerable<Table> GetTables()
    {
        ...
    }
    
    public IEnumerable<Column> GetTableColumns(Table table)
    {
        ...
    }
}

我对这种方法有点怀疑的原因有几个：

1. 我正在这个类中实现INotifyPropertyChanged，以便我可以更新 UI 以向用户显示他们是否已连接（例如，如果对服务器的任何调用失败，我可以将其切换为 false）。出于这个原因，它似乎表现得像一个 ViewModel（而不是一个服务）。

2. 我不确定在服务类上具有表示其状态的属性是否是一种好习惯，例如ConnectionInfo、IsConnected。

上面的设计看起来是可以接受的吗？

更新：进一步的思考和解释

我想我要解决的特定编程问题是，例如，我可能有一个用于 SQL Server 凭据的类和一个用于 Oracle 凭据的类，两者都是IConnectionCredentials。然后我会有几个对应的IDataService 实现，它们接受IConnectionCredentials 作为参数。问题是并非所有IDataService 的实现都可以与IConnectionCredentials 的所有实现一起工作，这对我来说似乎有缺陷，所以我认为将数据访问层和“数据访问器”对象组合到一节课。我想让IDataService 包含确定要使用哪个版本的“真实”数据访问接口的逻辑可能是可行的。例如：

public class DataService : IDataService
{
    private readonly RealDataServiceFactory RealDataServiceFactory;
    
    public IEnumerable<Table> GetTables(IConnectionCredentials connectionCredentials)
    {
        return RealDataServiceFactory.Create(connectionCredentials).GetTables(connectionCredentials);
    }
}

public class RealDataServiceFactory
{
    public IRealDataService Create(IConnectionCredentials connectionCredentials)
    {
        if (connectionCredentials is SqlServerConnectionCredentials)
        {
            return new SqlServerDataService();
        }
        else if ...
    }
}

我想要在数据访问类中使用IsConnected 属性的另一个原因是，除了连接不工作之外，服务可能不返回数据还有其他原因，而且我没有感觉到确定属于的逻辑调用类，因此喜欢数据服务可以同时返回 null 到某个调用以及向应用程序和 UI 状态的想法，“我的连接有问题”。在上面的实现中，我也会失去这个，虽然我想这可以通过在返回之前将传入的IConnectionCredentials 上的数据服务标记为IsConnected 来实现。

Answer 1

这最终取决于您要做什么，但听起来这种设计将两个（或更多？）关注点合二为一：

• 用户界面更新 (INotifyPropertyChanged)
• 数据访问

这给了班级不止一个改变的理由。换句话说，它违反了Single Responsibility Principle (SRP)。

现在，没有人说您必须遵守 SRP。这和其他SOLID principles 是处理某些复杂性的指南。如果您没有 SOLID 解决的问题，那么您不必遵循这些原则。

但在实践中，很难预测未来的问题。代码库从一开始就很少有问题。它慢慢地从简单的事情转向更复杂的事情。

虽然提议的设计听起来像是混合了关注点（而不是关注点分离），但实际上它可能是良性的。毕竟，INotifyPropertyChanged 是一个基类库接口，所以您没有引入与某些特定技术的耦合。不过，我会警惕扩大该类上与 UI 相关的更新范围。