我有一个“采购订单”课程。它包含有关单个采购订单的信息。我有一个用于数据库方法的 DAO 类。
负责加载和更新采购订单的方法的责任在哪里？
PurchaseOrder 类是否应该具有直接使用 DAO 类的“.update”、“insert”、“delete”和“.load”方法，或者 PurchaseOrder 类是否应该不了解 DAO 方法并具有管理这些方法的 POController 类互动？
用户一次只能处理一个 PurchaseOrder。
谢谢！
问问题
345 次
8 回答
4
采购订单应该不知道其持久性的细节。这就是拥有某种数据访问层的意义所在，它处理对象的管理，而对象本身可以专注于只是一个采购订单。
这也使系统更易于测试，因为您可以创建模拟采购订单并测试系统如何处理它们的逻辑，而不会陷入持久性问题。
于 2008-10-03T15:13:04.397 回答
1
我会通过使 PurchaseOrder 成为接口并将所有 DAO 代码放入实现中来保持简单，然后使用工厂。
于 2008-10-03T15:42:08.067 回答
0
这取决于您认为您的应用程序将存在多长时间。我公司的金属切削应用程序自 1985 年以来一直在不断发展，并通过计算机架构的多次变化进行移植。在我们的例子中，我们几乎总是将事情推到接口（或使用您的术语的控制器类）后面，因为我们不知道 5、10、15 年后的事情状态。
通过使用控制器类，我们可以更改底层 API，而不会篡改上面的业务逻辑级别和 UI 调整。这些级别代表了多年的工作，因此保持他们的行为很重要。
请记住，您的项目将在生命周期中的大部分时间处于维护状态。您现在所做的任何使以后更改设计变得更容易的事情都将在以后节省大量时间。
于 2008-10-03T15:17:05.497 回答
0
PurchaseOrder 类应该不知道 DAO。purchaseOrder 类应该代表数据本身，仅此而已。使用控制器或服务管理器或任何您想要调用它的东西来使用 DAO 持久/加载 PurchaseOrder 记录。这为您的设计提供了最大的灵活性。您有一个数据模型的位置，一个用于存储/检索 PurchaseOrders 的业务逻辑（控制器）的位置，以及一个实际持久化的位置。
于 2008-10-03T15:20:09.593 回答
0
让我带你了解我的推理：
类方法
基本原则：持久性是一种类行为，应该是一种类方法
你需要关注点分离，所以你把数据库的细节放在一个DAO类中，并使用类中的它来实现方法。
第一个问题：如果您需要支持不同的 DAO 集，您需要通过工厂创建它们。第二个问题：并非所有持久性行为都与类的实例特别相关。例如 List 和 Search 方法：它们返回类列表，而不是类，并且不依赖于实例。所以它们基本上是静态方法。
第三个问题：你想支持这个类的继承。因此，持久性细节因父母而异。如果您有静态方法，那将是一个问题。
所以你继续
控制器
基本原理：持久化方法不属于单个类，它们更大，因此应该分开
。再次需要关注点分离，因此需要DAO。这是一个 Utility 类，所以方法基本上都是静态的。
第一个问题：如果你想支持多个持久化方法，你需要一个工厂来创建 DAO。
第二个问题：你想支持类的层次结构，所以你不能使用静态类。您需要通过工厂生成控制器。
第三个问题：您正在向开发人员提供过于复杂的 API。
客户端代码示例：
PurchaseOrder po;
PurchaseOrderController poc;
poc = PurchaseOrderControllerFactory.Instance.Create();
po = poc.GetPurchaseOrder(42);
// do stuff
poc.SavePurchaseOrder(po);
然后我会从头开始。
Start from behaviours
Basic principle: Persistence is not a behaviour. Behaviours are larger than persistence.
In your system there will be a Purchase Order subsystem. Your user will be able to interact with it only at high level (use case level). So,the methods will implement Purchase Order use cases. These methods will use DAOs, through a factory if needed, to access the database and do whatever they need to do.
In short, your PurchaseOrder is basically a DTO, a quick way of passing data around. It should not have behaviours.
Example of client code:
// It could be a factory if needed.
PurchaseOrderSystem pos = new PurchaseOrderSystem();
List<PurchaseOrder> transacted;
transacted = pos.TransactPurchaseOrders(john, 23);
// Show transacted purchase orders or whatever...
于 2008-10-03T16:24:32.630 回答
-1
我肯定会将“业务逻辑”（PurchaseOrder）与数据库交互/访问分开。如果您转移到不同的供应商等，您将更容易对访问进行更改而不会潜在地干扰业务实施，而且您将更容易避免向数据库访问层添加行为。
于 2008-10-03T15:12:51.840 回答
-1
就个人而言，我会创建一个管理交互的对象。我不能为不将此逻辑放在 PurchaseOrder 类本身中提出强有力的理由，但创建此控制器对象会导致更松散耦合的对象。
于 2008-10-03T15:16:16.747 回答
-1
这里要考虑的关键是您将来可能想做的事情。也许你想用另一个替换你的数据库？这就是为什么您绝对应该将用于与数据库交互的代码与代表 PO 的类分开的原因。这是基本的职责分离，我希望你已经做到了。
现在的问题是：您是否想要第三个类（控制器）来管理 PO 和 DAO 类之间的交互？我认为这取决于您可以为 DAO 类创建接口的通用程度。如果 DAO 接口足够通用，您可以使用不同的存储机制编写插件替代它，但不更改接口，那么我会让 PO 类与之交互。如果没有，那么我会编写一个控制器类。
要考虑的另一件事是结构的其余部分。保存/加载从哪里开始？如果您要对 PO 进行大量操作（保存、加载、打印、发送给客户），那么拥有一个控制器来完成所有这些操作而不是将功能集成到 PO 类中可能是有意义的. 它为您提供了无需修改 PO 类即可添加 PO 操作的优势。
于 2008-10-03T15:22:43.880 回答