在阅读一些Java EE Projects时，我发现这些项目的结构，框架很复杂，可能没有必要，不是吗？
用户控制器 1 个文件
UserService,UserServiceImpl 2 个文件
UserDao,UserDaoImpl 2 个文件
我的工作很简单，只是 CRUD，当我改变一些东西时，我必须编辑除非 4 个文件，效率很差，不是吗？ 这些层设置会改变性能的影响吗？
Usercontroller - UserService 扩展 BaseService - BaseDao 这些更简单更有效，还是更高效？
如果你有 2 份工作，互联网 web 项目和企业错误
你能告诉我你对层结构的看法吗？
【问题讨论】：
标签： spring-mvc
没有什么可以阻止您直接在控制器中查询数据库。然而有一天你会意识到：
您希望与 Web 服务共享您的业务逻辑。突然你意识到所有的业务逻辑都在你的控制器中。您必须将其提取到单独的类中（称为服务层）并重用来自控制器和 Web 服务的代码
前几天有人决定从mysql 切换到oracle。突然间，您会发现到处都是原生数据库 SQL 查询（不再在控制器中，而是在服务中）。为了可维护性，您决定将所有与数据库相关的代码移动到单独的类（称为持久层或DAO层）
再次迁移到 Oracle 数据库后，您被要求切换到 mongodb。但不是重写现有的UserDao，而是将其更改为接口，将原始实现保留在OracleUserDao 中并创建第二个实现称为MongoDbUserDao
在单元测试期间，您发现模拟服务类很麻烦。此外，在类中很难看到业务方法，因此您可以使用定义明确的 API 提取服务接口
你猜怎么着，没有人强迫你遵循 三层架构 - 但它在开发过程中自然而然地出现。您可以等待，也可以从第一天开始。
【讨论】：
取出与您的层实现紧密耦合的接口，一旦您想模拟某些东西并在测试中使用该模拟，这将是一个问题。你有测试套件，不是吗？
除此之外，编程与接口可让您随时更改实现。因此，在不更改其他层的代码的情况下，您可以例如连接到远程服务层而不是本地服务层。
【讨论】：