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

时间:2017-09-20 01:29:37

标签: c# database class interface

我是编程新手,我正在尝试使用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);

}

2 个答案:

答案 0 :(得分:0)

我建议使用实体框架,它解决了所有问题

答案 1 :(得分:0)

我不确定为什么人们会评论 (使用)而不是如何(构建/编写更好的代码)。

  

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

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

  

我想知道我在创建IDatabase接口然后在Database类中实现它的路径是否有意义

一般来说,这是多少建筑师设计系统。你可以称之为IDatabase但是你真的建议/揭露它是如何做的。 在我的意见中你可以称之为IDataAccess这是更一般的(如果你把所有东西存放在json或xml中......如果你在数据库中存储的那些数据,你的数据访问可以甚至是外部网络api调用另一个系统......谁知道!)。

看看SOLID object oriented design特别是L和我。

通常,我所做的就像是一个公开数据访问的项目:

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 Framework。这意味着我只暴露了界面。这也意味着我可以用NHibernate或DAO或Dapper完全重写它,从该程序集(项目)注册该版本,只要我遵循接口定义,任何依赖于dataaccess的东西都不会关心如何< / em>我实现了它。

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