企业应用程序可以轻松地运行到数千个类中。例如，如果使用了200个表，那么只有DTO和DAO可以生成400个类。添加大约500个jsps和500个表单bean以及1000个操作，并且很容易接近3000个类。
答案 0 :(得分：2)
将类添加到任何Java应用程序（JavaEE或非JavaEE）的最重要影响是加载类的成本。每个类都有少量开销，但必须从磁盘加载到Java堆中。从磁盘加载类可能会降低服务器启动速度，或者响应第一次需要动态加载代码的某些操作。但是一旦课程被加载，他们几乎就会留下来。
另一个影响是许多类最终将最终出现在Java Heap的PermGen部分中。 Java应用服务器因“运行PermGen”而臭名昭着，因为应用程序在开发过程中会多次重载，但是当重新加载应用程序时，JDK，App Server和程序本身的错误仍然落后。
PermGen也是一个应该在启动命令中专门配置为Java选项的项目。
但除此之外，以及Jan提到的65K类限制，添加类对运行Java EE应用程序没有实际可测量的影响。
附录：
在现代JavaEE的许多情况下，实体替换DTO，EntityManager（可能使用轻量级包装器）成为通用DAO。这不是一个普遍的事实。我们自己来回走动，我们重新引入模型主要是作为数据的外部视图，而实体代表数据的内部视图。但是，我们仍然将EntityManager周围的光包装器作为通用DAO。
模型作为一个术语有一点包袱，DTO也许是一个更好的术语，因为它们肯定不是最丰富的领域对象。
您还可以创建一个层，例如，从JSON对象或XML DOM直接映射到您的实体（再次，使用这些构造作为上面的模型），但大多数人喜欢使用工具来做到这一点，所以他们可能会他们的Model类JSON / XML友好，让工具包编组到Models，你的图层编组来自Models - ＆gt;实体。
我仍然没有真正考虑模型DTO，至少不是经典意义上的。在以前的日子里，我们使用DTO只是为了从持久层中获取数据，所以我们可以完全依赖它。现在，我们直接使用实体。这些模型充当了我们对外界的代表。这可以说是一个有争议的问题，因为许多应用程序都倾向于服务提供者（通过SOAP或HTTP Web服务），在某些方面使应用服务器成为“持久层”。但是，这就是我们在内部查看它们的方式。更多关于你所在的围栏的哪一侧。
对于像Account（而不是String）之类的类，在操作上，这只是有点远。当然也有例外，但是大多数都是在通用字符串（或其他原语）之上的薄薄的单板，它很少值得花费时间来构建周围的基础设施并说服工具来回编组它们（即帐户＆lt; - ＆gt;字符串）。当然，它对多列密钥有意义，但我们甚至偏离它 - 我们从不在现代数据库中使用它们。
在某种程度上，这似乎是有道理的，但是当你完成工作时，在我的经历中似乎更多的工作而不是价值。