我正在研究商业模式和UML。我读到"模型"是一系列"业务对象"。
据我所知，模型是"博客"，而业务对象可以是"发布"和"评论"。"博客"决定使用哪些对象以及如何使用适当的映射器保留它们。
我拼凑了一些UML图来探索这个概念，它看起来确实很合乎逻辑。但是我有点困惑：
问题#1 - 在Joomla中，模型似乎代表一个单一的"业务对象"（而不是协调多个业务对象和映射器）。Joomla是否采用了不同的模型方法？
问题 #2 - "映射器"对象是否可以在查询中执行左联接？还是应该将这种逻辑移到"服务"层？
利用数据库的左连接功能似乎是最合乎逻辑的，但我无法弄清楚这如何适应（映射器 + 业务对象 + 模型 + 服务）设计。
在许多框架和应用程序中，您会发现模型=业务对象，并且通常映射器被内化为所有其他扩展的某种单一基本模型。您还会发现其中许多缺少定义明确的服务层。
这将纳入您关于映射器和服务的第二个问题。我通常不使用服务层，但理想情况下，您的映射器将从数据库提供数据，我认为这些数据通常驻留在服务层中，然后将该数据映射到业务对象中。但是，在使用映射器时，我经常将特定于表的数据库逻辑直接集成到专用或受保护范围内的映射器中。
然而，在大多数情况下，我使用的是通常实现活动记录的ORM，因此就您如何描述映射器本身而言，映射器本身并没有真正的隔离，然后倾向于以我上面描述的方式在我的第一段中运行。
此外，Joomla可能不是研究这些概念的最佳应用程序。实际上，大多数像这样的PHP应用程序都不是很好的例子，无论是Joomla，PHPBB，Drupal还是其他：-）
在 java 语言中，持久性注解在代码中作为 java 注解编写。这真的很酷，因为您可以专注于对象，从而在类图中对应用程序进行建模。
请注意，只有类图具有真正的等效代码，而其他关系图将模型驱动开发与代码生成器一起使用。这一点很重要，因为只有类图可以同时用于业务对象和映射器。
您仍然可以使用 AndroMDA 并使用代码生成器创建持久性层，但我认为这种方法在使用 Java 代码时现在已经死了。
它是如何工作的。您可以对类图进行建模，以在类图中创建应用程序的静态对象（例如包、类、接口、枚举等）。然后添加持久性构造型，这将立即在代码中创建 java 注释。最后，要创建数据库，您只需要使用Hibernate映射器，它将在条目中获取java代码并生成数据库。在部署阶段，您需要直接在与数据库相关的代码sql查询中编码，但这是最新的，通常不是可以在离岸国家完成的关键开发