向JavaEE应用程序添加类的成本是多少

企业应用程序可以轻松运行到数千个类中。例如，如果使用了200个表，那么只有DTO和DAO就可以生成400个类。添加大约500个JSP、500个表单bean和1000个操作，很容易接近3000个类

向项目中添加类的成本是多少

我应该想办法限制课程的数量吗

如果班级数量接近20000，这会不会没有区别

---

将类添加到任何Java应用程序（JavaEE与否）的最大影响是加载类的成本。每个类都有少量开销，但不可避免地必须从磁盘加载到Java堆中。从磁盘加载类可能会降低服务器启动速度，或者对某些需要首次动态加载代码的操作做出响应。但是一旦类被加载，它们就基本上停留在周围

另一个影响是，许多类最终会出现在Java堆的PermGen部分。Java应用程序服务器因在开发过程中多次重新加载应用程序而臭名昭著，因为“PermGen用完了”，但由于JDK、应用程序服务器和程序本身中的错误，在重新加载应用程序时仍然存在

PermGen也是一个项目，应该在start-up命令中专门配置为Java选项

但除此之外，以及Jan提到的65K类限制，添加类对运行JavaEE应用程序没有真正可测量的影响

增编：

在现代JavaEE的许多情况下，实体取代DTO，EntityManager（可能带有轻量级包装器）成为通用DAO。这不是一个普遍的真理。我们自己也反复强调，我们重新引入的模型主要是作为数据的外部视图，而实体代表数据的内部视图。然而，我们仍然将EntityManager作为通用DAO使用轻型包装器

作为一个术语，模型有一点包袱，DTO可能是一个更好的术语，因为它们肯定不是最丰富的域对象

您还可以创建一个从JSON对象或XML DOM直接映射到实体的层（同样，将这些结构作为上面的模型使用），但大多数人都喜欢使用工具来实现这一点，因此他们可以使他们的模型类JSON/XML友好，并让工具包封送到模型，而您的层从模型->实体封送

我还没有真正考虑模型DTOS，至少在经典意义上不是这样。在过去，我们使用DTO只是为了将数据从持久层中取出，这样我们就可以处理它了。现在，我们直接使用实体。这些模型充当我们对外部世界的代表。这是一个有争议的观点，因为许多应用程序倾向于成为服务提供者（通过SOAP或HTTP web服务），在某种程度上使应用程序服务器成为“持久层”。但是，这是我们内部的看法。更重要的是你站在哪一边

对于帐户（而不是字符串）之类的类，从操作上讲，这只是有点远。当然也有例外，但大多数例外情况都是在通用字符串（或其他原语）之上的一层薄薄的饰面，因此似乎很少值得费心构建周围的基础结构并说服工具来回封送它们（即帐户字符串）。当然，这对于多个列键是有意义的，但我们甚至偏离了这一点——我们从未在现代数据库中使用这些键

---

从某种程度上讲，这似乎是有道理的，但在我的经验中，当你放下手头的工作时，工作似乎比价值更重要

我认为有一个65536类的限制，在这一点之后，引用超过这个数量的类将在规模上得到显著的增长。或者是256个类和65536是一个硬限制？听起来像是一个维护噩梦。自从Java8以来就没有PermGen了。多谢你的回答。要为我的问题添加更多细节。。。我们得到了一些建议，比如“为什么我们不为每个模块设置一个DAO”和“让我们为一些不太重要的表使用hashmaps而不是DTO”。我认为我不应该把我的领域模型搞砸，但无论如何我都需要一些好的理由。此外，还有一种理念，就是让每个概念都成为一门课。。。例如，帐户号可以是具有单个成员字符串的类。再次感谢。在考虑课程成本时，还有另外两点。。1.类是否被垃圾收集（至少是没有静态的类）2。jar文件的大小是否表示类将占用的内存的常规大小或最大大小？如果类路径中有一个未使用的jar，它会浪费内存吗？我在这里找到了未使用jar问题的答案：