blocks|key|3935419|text|采购订单应该忽略其持久性的细节。这就是拥有某种类型的数据访问层的意义所在，它处理对象的管理，并且对象本身可以专注于仅仅是一个购买订单。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3935420|这也使系统更易于测试，因为您可以创建模拟采购订单并测试系统如何处理它们的逻辑，而不会陷入持久性问题。|3935421|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

The Purchase Order should be ignorant of the details of its persistence. This is the point of having some sort of data access layer, it handles the management of the object and the object itself can concentrate on just being a purchase order.

This also makes the system easier to test, as you can create mock Purchase orders and test the logic of how the system handles them without getting entangled in persistence issues.

blocks|key|3089756|text|为了简单起见，我将PurchaseOrder作为接口，并将所有DAO代码放在实现中，然后使用工厂。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3089757|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I'd keep it simple by making PurchaseOrder an interface and putting all the DAO code in the implementation, then use a factory.

blocks|key|801381|text|这取决于您认为您的应用程序将存在多长时间。我公司的金属切割应用程序自1985年以来一直在不断开发，并通过计算机体系结构的多次变化进行了移植。在我们的例子中，我们几乎总是把东西推到接口(或者使用你的术语的控制器类)后面，因为我们不知道5年、10年、15年后的情况。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|801382|通过使用控制器类，我们可以更改底层API，而不会篡改上面的业务逻辑级别和UI调整。这些级别代表多年的工作，因此保留他们的行为是很重要的。|801383|记住，在你的项目生命周期的大部分时间里，你的项目都处于维护阶段。您现在所做的任何事情都将在以后更容易地更改设计，从而节省大量的时间。|801384|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

It depends on how long you think your application will remain in existence. My company's metal cutting application has been continuously developed since 1985 and has been port through multiple changes in computer architectures. In our case we nearly always shove things behind a interface (or controller class using your terms) because we don't what going to be the state of things 5, 10, 15 years down the line. 

By using a controller class we can change the underlying APIs without tampering with the levels of business logic and UI tweaks above. These levels represent years of work so it is important to preserve their behavior. 

Remember the majority of the lifetime your project is going be in maintenance. Anything you do now to make it easier to change the design later will pay off in enormous time savings down the road.

blocks|key|3089660|text|PurchaseOrder类应该不知道DAO。purchaseOrder类应该表示数据本身，仅此而已。使用控制器或服务管理器或任何您想使用的名称来使用DAO持久化/加载PurchaseOrder记录。这为您的设计提供了最大的灵活性。数据模型有一个位置，业务逻辑(控制器)有一个位置，说明PurchaseOrders是如何存储/检索的，还有一个地方实际持久化了its。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3089661|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

The PurchaseOrder class should be ignorant of the DAO. The purchaseOrder class should represent the data itself and nothing more. Use a controller or service manager or whatever you want to call it to persist/load PurchaseOrder records using the DAO. This gives you the most flexibility in your design. You have one place for your data model, one place for your business logic (the controller) on how PurchaseOrders are stored/retrieved and one place where its actually persisted.

blocks|key|5345147|text|让我给你讲讲我的推理：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5345148|类方法|offset|length|style|BOLD|5345149|基本原则:持久化是类行为，应该是类方法|5345150|您需要分离关注点，因此您将数据库放在一个DAO类中，并使用该类中的数据来实现方法。|5345151|第一个问题:如果你需要支持不同的DAO集合，你需要通过一个工厂来创建它们。第二个问题:并不是所有的持久化行为都与类的实例特别相关。例如List和Search方法:它们返回类列表，而不是类，并且不依赖于实例。因此，它们基本上都是静态方法。|5345152|第三个问题:你想在这个类上支持继承。因此，不同的父级和子级的持久性细节是不同的。如果你有静态的方法，这将是一个问题。|5345153|因此，您可以转到|5345154|控制器|5345155|基本原则:持久性方法不属于单个类，它们更大，因此应该将它们分开|5345156|再次需要分离关注点，因此您需要DAO。这是一个Utility类，所以方法基本上都是静态的。|5345157|第一个问题:如果您想支持多个持久化方法，则需要一个Factory来创建DAO。|5345158|第二个问题:您希望支持类的层次结构，因此不能使用静态类。您需要通过Factory生成控制器。|5345159|第三个问题:你给你的开发者提供了一个过于复杂的API。|5345160|客户端代码示例：|5345161|PurchaseOrder+po;
PurchaseOrderController+poc;
poc+=+PurchaseOrderControllerFactory.Instance.Create();
po+=+poc.GetPurchaseOrder(42);
//+do+stuff
poc.SavePurchaseOrder(po);|code-block|syntax|javascript|5345162|然后我会从头开始。|5345163|从behaviours开始|5345164|基本原则:坚持不是一种行为。行为比坚持更重要。|5345165|在您的系统中将有一个采购订单子系统。您的用户将只能在高级别(用例级别)与其交互。因此，这些方法将实现采购订单用例。如果需要，这些方法将通过工厂使用do来访问数据库并执行它们需要做的任何事情。|5345166|简而言之，您的PurchaseOrder基本上就是DTO，一种快速传递数据的方法。它不应该有行为。|5345167|5345168|//+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...|5345169|entityMap^0|0|0|3|0|0|0|0|0|0|0|3|0|0|0|0|0|0|0|0|0|0|B|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1Q|8|@$D|1R|E|1S|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|1T|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|1U|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|1V|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|1W|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|1X|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|1Y|8|@$D|1Z|E|20|F|G]]|9|@]|A|$]]|$1|T|3|U|5|6|7|21|8|@]|9|@]|A|$]]|$1|V|3|W|5|6|7|22|8|@]|9|@]|A|$]]|$1|X|3|Y|5|6|7|23|8|@]|9|@]|A|$]]|$1|Z|3|10|5|6|7|24|8|@]|9|@]|A|$]]|$1|11|3|12|5|6|7|25|8|@]|9|@]|A|$]]|$1|13|3|14|5|6|7|26|8|@]|9|@]|A|$]]|$1|15|3|16|5|17|7|27|8|@]|9|@]|A|$18|19]]|$1|1A|3|1B|5|6|7|28|8|@]|9|@]|A|$]]|$1|1C|3|1D|5|6|7|29|8|@$D|2A|E|2B|F|G]]|9|@]|A|$]]|$1|1E|3|1F|5|6|7|2C|8|@]|9|@]|A|$]]|$1|1G|3|1H|5|6|7|2D|8|@]|9|@]|A|$]]|$1|1I|3|1J|5|6|7|2E|8|@]|9|@]|A|$]]|$1|1K|3|14|5|6|7|2F|8|@]|9|@]|A|$]]|$1|1L|3|1M|5|17|7|2G|8|@]|9|@]|A|$18|19]]|$1|1N|3|-4|5|6|7|2H|8|@]|9|@]|A|$]]]|1O|$]]

Let me walk you through my reasoning:

Class methods 
Basic principle: Persistance is a class behaviour and should be a class method 
You need separation of concerns, so you put the database nitty-gritty in a DAO class, and use that from the class to implement the methods. 
First problem: if you need to support different sets of DAOs you need to create them through a Factory.
Second problem: not all persistence behaviours are specifically related to an instance of the class. For example List and Search methods: they return Class lists, not classes, and do not depend on an instance. So they are fundamentally static methods. 
Third problem: you want to support inheritance on this class. As such, the persistence details differ from parent to child. If you have static methods, it's going to be a problem.

So you move on to the

Controller 
Basic principle: Persistence methods do not belong to a single class, they are larger and thus they should be separated 
Separation of concerns is needed again, so you need DAOs. This is a Utility class so methods are all basically static. 
First problem: you need a Factory to create the DAOs if you want to support more than one persistence method. 
Second problem: you want to support a hierarchy of Classes so you can't use a static class. You need to generate the Controllers through a Factory. 
Third problem: you are offering an overcomplicated API to your developers. 
Example of client code:

<pre><code>PurchaseOrder po;
PurchaseOrderController poc;
poc = PurchaseOrderControllerFactory.Instance.Create();
po = poc.GetPurchaseOrder(42);
// do stuff
poc.SavePurchaseOrder(po);
</code></pre>

then I would start from scratch.

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:

<pre><code>// It could be a factory if needed.
PurchaseOrderSystem pos = new PurchaseOrderSystem(); 

List&lt;PurchaseOrder&gt; transacted;
transacted = pos.TransactPurchaseOrders(john, 23);

// Show transacted purchase orders or whatever...
</code></pre>

blocks|key|3935386|text|我肯定会将“业务逻辑”(PurchaseOrder)与数据库交互/访问分开。如果您转移到不同的供应商，等等，您将更容易对访问进行更改，而不会潜在地干扰业务实现，而且您将更容易避免向数据库访问层添加行为。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3935387|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I would definitely separate the "business logic" (PurchaseOrder) from the database interaction/access. Should you move to a different vendor, etc, you'll have an easier time making changes to the access without potentially interfering with the business implementation, plus you'll have an easier time avoiding adding behavior to the database access layer.

blocks|key|5344851|text|就我个人而言，我会创建一个管理交互的对象。我不能很好地解释为什么不把这个逻辑放在PurchaseOrder类本身中，但是创建这个控制器对象会导致更松散耦合的对象。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5344852|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Personally, I'd create an object that manages the interactions. I can't make a strong case for NOT putting this logic in the PurchaseOrder class itself, but creating this controller object would lead towards more loosely coupled objects.

blocks|key|801477|text|这里要考虑的关键问题是您将来可能想要做什么。也许你想用另一个数据库替换你的数据库？这就是为什么您应该明确地将与数据库交互的代码与表示PO的类分开。这是基本的职责分离，我希望你已经做到了。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|801478|现在的问题是:您是否需要第三个类(控制器)来管理PO和DAO类之间的交互？我认为这取决于你对DAO类的接口的泛化程度。如果DAO接口足够通用，您可以使用不同的存储机制编写一个插件来替代它，但不需要更改接口，那么我会让PO类与它交互。如果不是，那么我将编写一个控制器类。|801479|另一件需要考虑的事情是结构的其余部分。从哪里启动保存/加载？如果您要对PO执行大量操作(保存、加载、打印、发送给客户)，那么使用一个控制器来执行所有这些操作可能更有意义，而不是将功能集成到PO类中。它为您提供了一个优势，即您可以添加PO操作，而不必修改PO类。|801480|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

The key thing to think about here is what you might want to do in the future. Maybe you want to replace your database with another? That's why you should definitely separate your code for interaction with the database from the class that represents the PO. That's basic separation of responsibility, and I hope you've done that already.

Now the question is: do you want a third class (controller) to manage the interaction between the PO and DAO classes? I think that depends on how general you can make the interface to the DAO class. If the DAO interface is general enough that you could write a plug-in replacement for it using a different storage mechanism but without changing the interface, then I would let the PO class interact with it. If not then I would write a controller class.

The other thing to think about is the rest of the structure. Where is the save/load initiated from? If you are going to do a lot of manipulations of the PO (save,load, print, send-to-customer) then it probably makes sense to have a controller that does all of those things rather than integrate the functionality into the PO class. It gives you the advantage that you can add PO operations without having to modify the PO class.

I have a 'Purchase Order' class. It contains information about a single purchase order. I have a DAO class for database methods.

Where should the responsibility reside for the methods that will load and update the purchase order?

Should the PurchaseOrder class have '.update', 'insert', 'delete', and '.load' methods that use the DAO class directly, or should the PurchaseOrder class be ignorant of the DAO methods and have a POController class that manages these interactions?

The user will only be working on a single PurchaseOrder at a time.

Thanks!

Class data responsibilities

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

我有一个“采购订单”的课程。它包含有关单个采购订单的信息。我有一个用于数据库方法的DAO类。加载和更新采购订单的方法的责任应该在哪里？PurchaseOrder类是否应具有直接使用DAO类的“.update”、“insert”、“delete”和“.load”方法，或者PurchaseOrder类是否应忽略DAO方法并具有管理这些交互的POController类？用户一次只能在一个Purchase

问类数据职责
EN

回答 8

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问类数据职责EN

回答 8

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问类数据职责
EN