摘要： URI 应该定义为内容提供者类常量，还是分发到表包装类定义？有没有更好的方法来实现所有的东西？是否有单一的首选实施方式？如何打破相互依赖？
数据库表包装类：为了避免直接构造 SQL 命令（以创建抽象层），创建了如下类（具有各种常量和一些静态方法）来包装表。
数据库助手类：数据库助手类是数据库的抽象。它使用上面类似的表格包装器将处理更多表格的工作包装在一起。
内容提供者类：向AndroidXxxxContentProvider发送各种 URI 以查询/插入/更新/删除所需的数据。子类应该实现这样命名的ContentProvider方法和其他几个方法。每个数据操作方法都会解析 URI（通常使用UriMatcher实例），并决定应该做什么。
更新：我ContactsContract.java在 Android 核心部分找到了。这是减少相互依赖的方法吗？是不是那种解决方案：“当双方之间的事情变得太复杂时，把代理放在中间”？
摘要： URI 应该定义为内容提供者类常量，还是分发到表包装类定义？有没有更好的方法来实现所有的东西？是否有单一的首选实施方式？如何打破相互依赖？
我认为有一种首选的做事方式，就像你已经看到的那样，一个Contract类。ContentProviders这是android 网站上的指南中的下划线。
讨论将围绕您ContentProvier是否被出口。如果您的提供程序将被其他应用程序使用，那么肯定会使用一个Contract包装您的常量的类。从长远来看，这将使维护变得更容易，并且也更容易公开这些常量。
如果提供者是私有的，那么你也有其他选择，但我仍然会使用一个Contract类。我不会将常量放在数据库助手类中，因为它们确实不属于那里。在数据库表包装类和内容提供者类之间，我会选择ContentProvider该类，因为稍后您可能会决定删除数据库表包装类（在子类的情况下不会发生这种情况ContentProvider）。但是，正如我已经说过的，我仍然会使用Contract该类，即使现在没有导出提供程序，您将来可能会决定您确实想要公开它，并且一个Contract类将使该切换更容易。