Web 框架似乎总是偏离良好的 OO 代码(将代码和数据组合在一个对象中，考虑向该对象发送消息等)
主要问题似乎是 bean 模式的存在。您使用 bean 模式(现在通常称为 POJO，因为人们似乎不理解其中的区别)与数据库、Web 服务和大多数其他事物进行交互。
所以不，你被困在这个没有代码的 setter 和 getter 球中——所以你倾向于添加一堆——基本上是静态的函数来操纵这些东西。 OO 代码的所有优点几乎都消失了。
我看到了正在考虑的三种解决方案，但想听听它们中的任何一个是否存在严重的缺点。
1) 使用 POJO 模式而不是 bean 模式。这意味着从 POJO 中消除 setter 和 getter(这样您就可以实现封装/数据安全)，而是添加业务逻辑方法。这似乎是最有道理的——事实上，我认为这就是为什么像 hibernate 这样的库从要求 Bean 转向允许 POJO，但每个人似乎仍然使用 Bean 模式。
2) 使用业务逻辑类扩展您的 Bean，该业务逻辑类使用 Bean 的字段作为存储。这看起来很不稳定并且有问题，但是很容易将其作为迁移的方式放入现有的代码库中......
3) 用业务逻辑对象包装 Bean 模式对象。大多数情况下，我认为如果#1 确实有问题，这可能是必要的。
我最想知道的是为什么我从未见过#1被使用过。我真的很想听到任何使用 Pojo 模式(具有业务逻辑，没有 setter 和 getter)作为 hibernate 对象并且遇到问题(或者它工作得很好)的人的来信...
最佳答案
我会将我的评论更改为答案。我基本上不同意你的开场前提
Web frameworks seem to always wander away from good OO code.
Java EE 或 Spring/JPA 模型中没有任何内容“偏离了良好的 OO 代码”。像 hibernate 这样的 JPA 提供者允许 POJO 的事实并不意味着您不能使用定义 bean 中的业务逻辑的丰富域模型。对于 Java Web 应用程序，我看到它是通过两种方式实现的——丰富的域模型，或者业务逻辑位于服务层的贫乏域模型，这并不是非 OO 或糟糕的设计所必需的。
我想也许你的意思是很多应用程序都没有以正确的设计和/或正确的面向对象编写。 那我会同意。但这与框架无关......
所以你提出的解决方案基本上都是说“用良好的面向对象原则正确设计你的应用程序”。选项 1 是最简单的。
关于java - 寻找让Web框架在服务器端更加面向对象的最佳方式，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/12827458/