关于Java EE的框架和层，

Question

当我阅读一些Java EE项目时，我发现这些项目的结构，框架很复杂，可能没必要，不是吗？

Usercontroller 1文件

UserService，UserServiceImpl 2个文件

UserDao，UserDaoImpl 2个文件

我的工作很简单，只是CRUD，当我改变一些东西时，我必须编辑除非4个文件，效率低下，不是吗？ thoese层设置会改变性能的影响吗？

Usercontroller - UserService扩展BaseService - BaseDao 这些更简单，更有效，更高效吗？

如果您有2个工作，互联网网站项目和企业错误

你能告诉我你对层结构有什么看法吗？

Answer 1

没有什么可以阻止您直接在控制器中查询数据库。但有一天你意识到：

• 您希望与网络服务分享您的业务逻辑。突然间，您意识到所有业务逻辑都在您的控制器中。您必须将其提取到单独的类（称为服务层）并重用来自控制器和Web服务的代码

• 前几天有人决定从mysql切换到oracle。突然间，您可以在整个地方找到本机数据库SQL查询（不再在控制器中，而是在服务中）。为了可维护性，您决定将所有与数据库相关的代码移动到单独的类（称为持久层或 DAO层）

• 再次迁移到Oracle数据库后，系统会要求您切换到mongodb。但是，不是重写现有的UserDao，而是将其更改为界面，将原始实现保留在OracleUserDao中，并创建名为MongoDbUserDao的第二个实现

• 在单元测试期间，您发现模拟服务类很麻烦。此外，很难在类中看到业务方法，因此您使用定义良好的API提取服务接口

猜猜是什么，没有人强迫你遵循 3层架构 - 但它在开发过程中自然而然地出现。您可以等待它，也可以从第一天开始。

Answer 2

取出你正紧密耦合你的图层实现的接口，一旦你想要模拟一些东西并在测试中使用那个模拟，这将是有问题的。你有测试套件，不是吗？

除此之外，编程与界面允许您随时更改实施。因此，无需更改其他层的代码，您就可以连接到远程服务层而不是本地层。