java - 三层体系中，业务逻辑应该放在哪里？

Question

我知道关于我的问题有很多疑问，我也阅读了很多，但我仍然觉得有点愚蠢，因为我仍然没有得到它。所以我正在尝试解决我的特定问题。

我正在执行学校的工作。它应该是信息系统的一部分，必须分层。我们必须用 Java 或 C# 编写它(我选择了 Java)。我们必须使用两个不同的数据源和两个不同的 View ，在我的例子中，oracle db 和 xml 作为数据源，Java Swing 和 JSF 作为 View 。

根据“Martin Fowler 的企业应用程序架构模式”一书，主要分为三个层:

1. 数据源层:我使用 Hibernate ORM 生成了实体，我创建了数据访问对象来实现更简单的“接口(interface)”来获取数据。
2. 领域层: ...
3. 表示层:我创建了 Swing GUI 和一些带有 MVC 逻辑的 .xhtml 页面

如果系统中不会有任何“计算”，而只是简单的获取和返回数据，我就完了，一切正常。但是，例如，我正在实现一个系统，该系统应该管理运动舞蹈的比赛，在比赛期间我需要为每一轮生成一对，比赛结束后我需要计算每个舞者的分数，增加必要时加分等等。

我知道，这是领域层(业务逻辑)的责任，但我的代码在哪里？我应该为这些对象选择什么名称以及将它们放在我的代码结构中的什么位置？

我的结构:

• hibernate.cfg.xml(hibernate的配置)
• hibernate.reveng.xml(hibernate 逆向工程文件)
• isets.dao(包)
  • isets.dao.hibernate(包)
    • HbmCompetitionDao.java(竞赛实体的数据访问对象)
    • ...
  • isets.dao.xml(包)
    • ...(另一个实体的数据访问对象，存储为 XML)
• isets.entities(包)
  • Competition.hbm.xml(生成的实体)
  • Competition.java
  • ...
• isets.util(程序包)
  • HibernateUtil.java(获取 session 工厂对象的文件)

我应该在哪里放置我的业务逻辑以及这些类的名称应该是什么？

非常感谢您的帮助。再见:-)

Answer 1

通常领域层意味着“实体”(领域模型)和领域服务。

实体拥有与其相关的所有业务逻辑。验证(检查它们是否处于正确状态)和计算通常放在属性 setter / getter 中，而转换数据的操作通过公共(public)方法公开。

领域服务是与多个实体一起操作并在实体之间进行一些计算和/或转换的类。

需要考虑的几件事。为了使这个设计正常工作(因此它是可测试的、解耦的等)，必须使用依赖注入(inject)(DI)。 Domain 永远不应该被获取或保存数据等所困扰。它应该清楚地解耦，并且它的所有依赖项都应该预先知道。

如果它是一个简单的应用程序，结合领域层和数据访问层可能是明智的，因此从 ORM 创建的对象已经是实体。只需添加域服务(如果需要)。然后在演示文稿上使用相同的实体(作为 MVC 模型)。这将减少映射器在 ORM 制造的对象(我们称它们为 dbos)、实体和表示所需的可能模型之间进行映射的需要。当然，如果每一层都需要不同的对象，一定要创建它们。如果不需要，请不要过于复杂。