我应该为数据库连接/模型类使用接口吗

Question

我是编程新手，我正在尝试使用 WPF 创建一个简单的食堂/商店管理应用程序（这将是我构建的第一个真实世界应用程序）。我认为我应该克服的第一步是创建一个处理与数据库相关的所有方面的类。目前我正在使用 SQLite，但希望最终能够包括对许多不同数据库的支持。简而言之，我想就我在创建 IDatabase 接口然后在 Database 类中实现它所采取的路径是否有意义或者是否有更好的方法来提出意见。谢谢！我在下面包含了到目前为止我编写的代码。

public interface IDatabase
{
    bool IsConnected { get; }

    bool Connect(string connectionString);
    void Disconnect();

    List<Account> SearchAccounts(Account account);
    Account CreateAccount(Account account);
    Account GetAccount(int accountId);
    void DeleteAccount(int accountId);

    List<PersonCategory> SearchPersonCategories(PersonCategory personCategory);
    void AddPersonCategory(PersonCategory personCategory);
    PersonCategory GetPersonCategory(int CategoryId);

    List<Person> SearchPeople(Person person);
    Person CreatePerson(Person person);
    Person GetPerson(int personId);
    void DeletePerson();

    List<Transaction> SearchTransactions(Transaction transaction);
    Transaction GetTransaction(int transactionId);
    void AddTransaction(Transaction tansaction);

    List<Log> SearchLogs(Log log);
    Log GetLog(int logId);
    void AddLog(Log log);

    List<ProductCategory> SearchProductCategories(ProductCategory productCategory);
    void AddProductCategory(ProductCategory productCategory);
    ProductCategory GetProductCategory(int categoryId);
    void DeleteProductCategory(int categoryId);

    List<Product> SearchProducts(Product product);
    void AddProduct(Product product);
    Product GetProduct(int productId);
    void DeleteProduct(int productId);

}

Answer 1

我不确定为什么人们评论的是 what（使用）而不是 how（构建/编写更好的代码）。

我应该为数据库连接/模型类使用接口

很有可能。 这都是我的意见，所以我们开始。根据您正在开发的项目的规模或您尝试学习的内容，通常会决定您如何实施它。以下意见是我为大多数中型到大型应用程序编写代码的方式。

我想知道我在创建 IDatabase 接口然后在数据库类中实现它所采取的路径是否有意义

一般来说这是多少建筑师设计的系统。你可以称它为IDatabase，但你实际上是在暗示/暴露它是如何做的。 在我看来您可以将其称为 IDataAccess，这更通用（如果您将所有内容存储在 json 或 xml 中...从技术上讲，这些不是数据库，您的数据访问甚至可以是外部的web api 调用另一个系统...谁知道呢！）。

看看SOLID object oriented design，特别是L和I。

通常我会做一些类似于公开数据访问的项目：

Project <company>.DataAccess.csproj

namespace <companyname>.DataAccess
{
  // sometimes generic IMyDomainDA<IEntityType>
  public interface IMyDomainDA // I suffix it with DA for DataAccess
  {
    IEntityType Get();
    // etc
  }
}

Project <company>.DataAccess.<ImplementationType>.csproj

例如 Company.DataAccess.EF

namespace <companyname>.DataAccess.EF
{
  internal class MyDomainDA : IMyDomainDA
  {
    public IEntityType Get()
    {
      //Implementation
    }
  }
}

因为我使用依赖注入框架（特别是 Autofac，但你可以使用 Ninject 或 Unity 或 [在此处插入框架]）我可以将实现保留在内部，但将其注册到 DI 框架。这意味着我只公开接口。这也意味着我可以用 NHibernate 或 DAO 或 Dapper 完全重写它，从该程序集（项目）注册该版本，只要我遵循接口定义，任何依赖于数据访问的东西都不会关心 如何 我实现了。

这也意味着我可以测试依赖于接口的代码。我可以对接口进行 NSubstitute (moq, rhino mock) 并测试依赖于接口的代码调用正确的方法或任何它应该做的事情，而不需要真正的实现。

Answer 2

我建议使用实体框架，它可以解决你所有的问题