数据库驱动应用程序中的 OOP 建模对象？

Posted 2023-05-08

【中文标题】数据库驱动应用程序中的 OOP 建模对象？

【英文标题】：OOP Modelled Objects in a Database Driven App?

【发布时间】：2012-04-05 04:31:28

【问题描述】：

我已经基于 SQLite 数据库构建了一个完整的银行应用程序。今天我有一个恐慌的时刻。我一直在阅读有关 OOP 的各种文章，我相信我理解这个概念及其重要性，但是，我无法理解它在像我这样的应用程序中的位置。到目前为止，也许是无知的，我处理数据的逻辑如下（用于为新帐户应用程序编辑银行表单的示例伪代码）：

在EditAccountApplication Activity 中，定义一个公共Cursor，这个Cursor 将保存之前申请表数据的详细信息。 使用 DbHelper 中的方法在数据库中查询旧的应用程序表单数据，返回带有所述数据的 Cursor 对象。 使用此游标，填充 UI 组件（EditText、TextView 等）的值，然后用户可以使用这些值进行编辑以使用更新的数据重新提交他们的应用程序。 用户点击按钮重新提交申请表，在按钮的 onClick() 方法中，在 ContentValues 对象中为每个 UI 组件定义和设置变量，然后将此 ContentValues 对象传递回 DbHelper 的方法，该方法最终更新相关的数据库记录。

这是我在使用 SQLite 后端时应该采取的正确方法吗？在这种情况下，我没有看到建模对象会有什么帮助（光标几乎就是对象，我不需要操作它，因为 UI 元素可供用户操作）。

我真的很想了解这种情况是否是一种创建建模对象没有额外好处的情况。

我真的很感谢任何帮助，因为我现在吓坏了，所以现实检查将是一种解脱！

再次感谢！

【问题讨论】：

这是一个很有意思的话题，不过应该移到programmers.SE。

我已经更新了它，使它更具体，你知道它也可以移动吗？

这个答案很接近我的问题，不完全是，但非常接近：***.com/questions/1122679/…

【参考方案1】：

您已经在不知不觉中使用 OOP。在为 android 等平台编写移动应用程序时，您通常使用通用模式来执行常见任务（例如更新 Sqlite 后端）。这些模式要么在 Android Dev 页面上，要么在书中的 sn-ps 中，并且非常具体。所以很难偏离它们——而且它们“已经”是面向对象的。

现在，假设您将银行帐户对象的实例保存在应用程序的内存中，因此需要对 BankAccount 对象进行建模。在那里，您可以遵循 OOP 原则，例如封装和数据隐藏，例如拥有一个方法：

debitAccount(double amt) 
  // do validation checks for account balance such as don't let it go negative

在 BankAccount 类中并对其进行操作。或者，如果您要公开更新对象的 API，并且必须通知该更新的侦听器，那么您就有机会使用观察者模式显式建模 OOP。

但是对于更新 SQLite 数据库等简单任务，当您使用特定的 Android 模式时，代码已经是面向对象的。

恕我直言，你很好。

【讨论】：

谢谢 Sid，我完全明白了，Cursor 和 ContentValues 是我的对象。它们对我的应用程序的主要区别是物理存储与内存存储。当用户查看一个项目时，他们要么在该视图中对该项目进行操作，要么返回主视图。所有更改都在物理数据库存储中更新，因此没有任何内容在内存中传递。如果没有在内存中传递，那么一开始就真的没有必要将其对象化，是吗？

好吧，当您向用户显示这些项目时，它们已经在内存中。我认为不同之处在于这些项目（如 Text 等）已经是类并且遵循 OOP。假设您正在为自己的类建模，那么您需要更多地考虑 OOP。

如果您对此有更多疑问，请随时提问。

谢谢希德。我想我没有说清楚。我所说的物理存储与内存存储的意思是，我基本上每个视图操作一次对象，在移动到另一个视图之前将更新的对象存储在数据库中。话虽这么说，我不需要在内存中传递对象并保存它们的状态，它本质上是在数据库中完成的。你懂我的意思吗？数据库充当我的“对象”状态的持有者，而不是它们漂浮在内存中并需要我可以引用回的特定实例。你同意吗？我希望这有点道理。我同意，这些课程是 OOP :)

是的，我明白你在说什么 - 在像你这样的简单应用程序中，没有太多的对象操作发生，你显式建模 OOP 的需要大大减少。

【参考方案2】：

面向对象概念应用于给定应用程序的程度取决于您尝试解决的问题类型。您的问题是您是否应该在 begging the question 的数据驱动应用程序中使用面向对象的建模。也就是说，您已经以数据驱动的风格编写了您的应用程序（假设这是最适合手头问题的风格），并且正在询问合并来自不同架构范式的概念的正确方法。

如果您实际编写了一个完整的银行应用程序，那么您可能有用户界面问题、输入验证问题、银行业领域问题、数据访问问题等，并且您的架构可能会很好地遵循面向对象的设计原则.

如果您只有一个纯粹的表单数据 CRUD 应用程序，它没有业务逻辑并且不会随着时间的推移而发展以整合新功能，那么您的方法就可以了（尽管有许多快速应用程序编程工具可以您可能也可以通过几乎没有实际编码来解决这个问题）。

【讨论】：

谢谢德里克，我明白你的意思了。我确实必须验证问题，但是，它们在 DbHelper 类及其相关方法中很容易处理。通过 DbHelper 类运行所有数据库更改对我来说是有意义的，我想我已经创建了一个巨大的对象：DbHelper，这可能可以分成几个对象。最终，我想有两个测试：程序是否易于更新，错误是否易于跟踪和修复？目前我可以很容易地更新程序，并且错误也很容易消除。归根结底，我想这才是最重要的？