在代码中我最好将对象创建（有状态对象）放在哪里，而不放在哪里？在哪几层？
例如，我曾经在 Hibernate DAO 类中放置一个对象引用，我被告知这是不正确的，因为 DAO 类不应该有状态。状态应该在“服务层”内。
有人告诉我，我不应该在诸如 UpdateCart() 之类的重复方法调用上创建新对象。创建对象的成本很高，不应随处出现在您的代码中。它应该只位于初始化类型的方法中。例如，如果电子商务应用程序需要一个购物车，请将其放入会话中。如果它需要一些通用的主对象，把它放在初始化代码中。在那里创建一次，然后让应用程序的其余部分访问它的实例。不要在每次调用时创建此实例。
我对整个设计原则感到困惑。我听到的最奇怪的事情是‘一个应用程序不应该有状态。状态应该保存在数据库所在的数据层中。真的吗？我对这些设计概念很陌生，我不知道去哪里才能获得更多的教育。戈夫？设计模式书籍？目标是创建定性代码（即在业务中使用）。
谢谢
什么是好的做法可以根据项目的类型而有所不同。
对于大多数项目来说，创建对象对 CPU 来说并没有那么昂贵。设计成本并不总是能很好地表达出来。您的应用程序似乎有一种设计方法，其中所有状态和对象都需要以受控和集中的方式进行管理。通常这样做是为了提高可维护性和简化设计。我不会假设您应该只知道设计是什么，除非它已经非常清楚地向您说明。
我怀疑他们团队的其他成员习惯于以特定的方式工作，并且认为他们不应该记录或教你这种方法，只要告诉你什么时候“错误”。恕我直言，这不是有效的，但是当涉及到状态或数据结构的放置时，您必须处理您所遇到的情况并向他们提问。
'一个应用程序不应该有状态。状态应保存在数据库所在的数据层中'
有些设计符合规范，被恰当地称为“无状态架构”。是否每个架构都应该是无状态的当然是值得怀疑的，而且这个术语也可能会引起争论。
大多数“无状态”应用程序实际上确实有状态，但按照上述规则（无双关语），此状态保存在一个全局位置；数据库。正如 Peter 提到的，这样做的原因可能是可维护性和简化，但也经常听说这是为了scalability. 没有状态出现在数据库中的任何地方，它被认为很容易添加额外的前端服务器、处理服务器，以及你拥有的东西。
虽然这确实有一些优点，但我认为我们确实必须区分临时状态和权威状态。
临时状态可以是您在订购过程中所处的位置以及您已经输入的详细信息。在Java EE 中，您可以将其保留在例如@ConversationScoped bean 或@Stateful bean 中。因此，这是您保留在 Web 层内部的状态。业务层。
这样做的优点是易于使用、性能和卸载您的单个中央数据库。当然，您也可以将临时状态存储在中央数据库中，但您可能希望将其远离常规的非临时数据，这意味着需要一些额外的编程复杂性。从 Web 层检索数据通常也更快，并且它从数据库中移除了一些负载。
在许多系统中，只有一个主数据库（一个接受写入的数据库），因此这个单一数据库可能会成为该设置的巨大瓶颈。
根据您的实际架构和设置，不在数据库中保留临时状态可能实际上会提高您的扩展能力。
缺点是您确实需要您的客户端坚持使用当前保存临时状态的单个服务器。这就是典型的“粘性会话”。如果与该客户端交互的一台服务器出现故障或需要重新启动或其他任何情况，客户端将丢失此临时数据。有一些方案，例如将状态复制到集群中的所有节点或附近的节点（伙伴复制），但这会使事情再次变得复杂，并且可能会使网络过载（如果所有节点不断地相互复制）。
权威状态意味着它代表了作为唯一信息来源的共享数据。这种状态是我们几乎总是喜欢在一个中心位置拥有的东西，但有时你会看到它被存储在一个 web 节点中。
例如，假设我们有一个最近价格列表，而不是将其保存到中心位置，我们将其保存在输入它的 Web 节点上。现在有一个包含此信息的“唯一”网络节点的概念，其他服务器可能会开始假设只有这个“唯一”网络节点。现在不可能添加额外的节点，因为它打破了这个假设。