围绕DB访问组织Android代码

关于我的应用程序代码组织的一些背景故事：

现在，我正在使用一种用于DB访问的特殊ORM，其中每个表都被分割成一个模型，只是一个普通的Java类，不继承任何Android组件，它涵盖了正常的CRUD活动。 我没有使用内容提供商，因为所有这些数据都是应用程序的私有数据

我在应用程序的应用程序类中保留了databaseopenhelper和应用程序上下文的单例

class MyApplication extends Application {
  private static Context mContext;

  @Override
  public void onCreate() {
    super.onCreate();
    mContext = this;
    dbHelper = new DatabaseHelper(this); // Subclass of SQLiteOpenHelper
  }

  public static Context getContext(){
    return mContext;
  } 

所有涉及数据库的活动在Resume时打开数据库，在Pause时关闭数据库

在我开始单元测试之前，这似乎工作得很好，当时我遇到了第一个问题，即使用破坏单例的封装无法使用RenamingDelegatingContext对特定的测试数据库进行测试

所以

1有些事情告诉我，如果我不能正确地进行单元测试，我的体系结构就是废话——但是我想不出更好的方法来做这件事，没有显式地传递上下文和dbhelpers——这是一种痛苦

---

2如果这不是一个完全疯狂的想法，那么对该设置进行单元测试的最佳方法是什么？

为什么需要将上下文保存到应用程序的静态变量中？任何活动都是一个上下文，因此您可以随时通过它获取它。是什么阻止您在每个活动中创建DatabaseHelper？您所要做的就是创建一个抽象活动类，并每隔一段时间重用它的onCreateactivity@denis.solonenko我将上下文保存到静态变量中，因为我的模型类只是普通的Java类，不从任何Android组件继承。就像我说的，我可以传递我的上下文，但我觉得可能有一种更有效的方法。没有什么能阻止我创建一个新的DatabaseHelper，但是对象创建AFAIK是昂贵的，所以如果我只需要创建/销毁它的一个实例，为什么还要不必要地创建/销毁它呢？我会将上下文传递给我的模型类，特别是如果它消除了对全局单例的依赖并简化了测试的话。创建对象并没有那么昂贵——当然你可以为每一个活动多提供一个对象：我就是这么说的——因为你在任何给定时刻都不应该有多个实例，我觉得这属于创建不必要对象的定义范围。