1

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

用户控制器 1 个文件

UserService,UserServiceImpl 2 个文件

UserDao,UserDaoImpl 2 个文件

我的工作很简单，只是 CRUD，当我更改某些内容时，我必须编辑，除非 4 个文件，效率低下，不是吗？这些图层设置会改变性能吗？

Usercontroller - UserService 扩展 BaseService - BaseDao 做这些更简单更有效，还是更高效？</p>

如果你有 2 份工作，互联网 web 项目和企业错误

你能告诉我你对层结构的看法吗？

4

2 回答 2

3

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

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

  • 前几天有人决定从切换到。突然间，您会发现到处都是原生数据库 SQL 查询（不再在控制器中，而是在服务中）。为了可维护性，您决定将所有与数据库相关的代码移动到单独的类（称为持久层或DAO 层）

  • 再次迁移到 Oracle 数据库后，您被要求切换到。但是不是重写现有的，而是UserDao将其更改为接口，保留原始实现OracleUserDao并创建第二个实现，称为MongoDbUserDao

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

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

于 2012-04-08T10:40:33.253 回答
0

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

除此之外，编程与接口可让您随时更改实现。因此，在不更改其他层的代码的情况下，您可以例如连接到远程服务层而不是本地服务层。

于 2012-04-08T01:49:21.040 回答