商业模式+数据库映射器+连接

Question

我正在研究商业模式和UML。我读到“模型”是一系列“商业对象”。

根据我的理解，模型将是“博客”，而业务对象可以是“发布”和“评论”。 “博客”决定使用哪些对象以及如何使用适当的映射器保留它们。

我已经将几个UML图拼凑在一起来探索这个概念，它确实看起来很合乎逻辑。但是我有点困惑：

问题＃1 - 在Joomla模型中，似乎代表了一个单一的“业务对象”（而不是协调多个业务对象和映射器）。 Joomla是否对模型采用了不同的方法？

问题＃2 - “Mapper”对象在查询中执行左连接是否可以接受？或者这种逻辑是否应该移入“服务”层？

利用数据库的左连接功能似乎最合乎逻辑，但我无法弄清楚它是如何适应（Mapper + BusinessObject + Model + Service）设计的。

Answer 1

在许多框架和应用程序中，您会发现Model = Business Object，并且Mapper经常被内化到某种其他所有扩展的基本模型中。您还会发现其中许多缺少明确定义的服务层。

这将提供有关映射器和服务的第二个问题。我通常不使用服务层，但理想情况下，映射器将从数据库中提供数据，我认为它通常驻留在服务层中，然后将数据映射到业务对象中。但是，使用映射器时，我经常将特定于表的数据库逻辑直接集成到私有或受保护范围内的映射器中。

然而，在大多数情况下，我使用通常实现Active Record的ORM，因此就你如何描述它而言，mapper本身没有真正的隔离，然后倾向于以我在第一段中描述的方式运行

Joomla也可能不是研究这些概念的最佳应用程序。实际上，像这样的大多数PHP应用程序都不是很好的例子，无论是Joomla，PHPBB，Drupal还是其他： - ）

Answer 2

在java语言中，持久性注释在代码中被编写为java注释。这非常酷，因为您可以专注于对象，从而在类图中为应用程序建模。

请注意，只有类图具有实际代码等效，而其他图使用模型驱动开发和代码生成器。重要的是要看到只有类图可以用于Business对象和映射器。

你仍然可以使用AndroMDA并使用代码生成器创建持久层，但我认为这种方法在使用Java代码时已经死了。

工作原理。您可以对类图进行建模，以在类图中创建应用程序的静态对象（例如，包，类，接口，枚举等....）。然后添加持久性构造型，它将在代码中立即创建java注释。最后要创建数据库，您只需要使用Hibernate映射器，它将获取入口中的java代码并生成数据库。在部署阶段，您需要直接在与您的数据库相关的代码sql查询中进行编码，但这是最新的，通常是无关键的开发，可以在离岸国家完成