企业应用程序可以轻松运行数千个类。例如，如果使用了 200 个表，那么仅 DTO 和 DAO 就会产生 400 个类。添加大约 500 个 jsps 和 500 个表单 bean 和 1000 个操作，很容易接近 3000 个类。
【问题讨论】：
标签： java performance jakarta-ee jvm
向任何 Java 应用程序（JavaEE 或非 JavaEE）添加类的最显着影响是加载类的成本。每个类都有少量开销，但不可避免地必须从磁盘加载到 Java 堆中。从磁盘加载类可能会减慢服务器启动速度，或者响应某些需要第一次动态加载代码的操作。但是一旦加载了这些类，它们几乎就一直存在。
另一个影响是许多类最终会出现在 Java 堆的 PermGen 部分。 Java 应用服务器因“PermGen 耗尽”而臭名昭著，因为在开发过程中会多次重新加载应用程序，但由于 JDK、App Server 和程序本身中的错误，在重新加载应用程序时仍然存在。
PermGen 也是一个项目，应该在启动命令上专门配置为 Java 选项。
但除此之外，以及 Jan 提到的 65K 类限制，添加类对运行 Java EE 应用程序并没有真正可衡量的影响。
附录：
在现代 JavaEE 的许多情况下，实体取代了 DTO，而 EntityManager（可能带有轻量级包装器）变成了通用 DAO。这不是普遍的真理。我们自己也来回走动，我们重新引入模型主要是作为数据的外部视图，而实体代表数据的内部视图。但是，我们仍然将 EntityManager 的轻包装器作为通用 DAO。
模型作为一个术语有一些包袱，DTO 可能是一个更好的术语，因为它们肯定不是最丰富的域对象。
您还可以创建一个层，从例如 JSON 对象或 XML DOM 直接映射到您的实体（再次，使用这些构造作为上面的模型），但大多数人喜欢这样做的工具，所以他们可能会他们的模型类 JSON/XML 友好，并让工具包编组到模型，并让您的层从模型 -> 实体编组。
尽管如此，我仍然没有真正考虑 Models DTO，至少不是在经典意义上。在过去的日子里，我们使用 DTO 只是为了将数据从持久层中取出，这样我们就可以处理它了。现在，我们直接使用实体。这些模型充当我们对外部世界的代表。这可能是一个有争议的问题，因为许多应用程序倾向于成为服务提供者（通过 SOAP 或 HTTP Web 服务），在某些方面使应用程序服务器成为“持久层”。但是，这就是我们内部看待它们的方式。更重要的是你站在栅栏的哪一边。
对于像 Account（而不是 String）这样的类，在操作上，这有点远。当然也有例外，但大多数都是在通用字符串（或其他原语）之上的薄薄的一层，似乎很少值得费心去构建周围的基础设施并说服工具来回编组它们（即帐户 字符串）。当然，多列键是有意义的，但我们甚至偏离了这一点——我们从不在现代数据库中使用这些键。
在某种程度上，这似乎是有道理的，但是当你在工作中感到沮丧时，根据我的经验，工作似乎比价值更重要。
【讨论】：