Question

我目前正在开发一个ZF2应用程序，并希望实现它与ZF2 example Blog application非常相似。可能在将来，DAL将被Doctrine取代，但在第一个版本中，模型应该像Blog应用程序一样工作：Service + Mapper + Data Objects。

在博客应用程序中，方法ZendDbSqlMapper#save(...)获取（与Mapper的所有其他公共方法一样）数据对象作为参数，将其提取，然后将数据写入数据库。但我的真实情况有点复杂，我不（但想）理解这种方法是否仍然适用于它以及如何。

应用程序应主要处理（保存和检索）某些技术服务的请求/订单。（在下一步中，它们由员工手动处理并实施。）因此，常见的情况是Order的保存（更新/创建）。

物理模型如下所示：

正如您所看到的，Order有一些依赖项，也有依赖项等。在创建Order时，我必须先创建LogicalConnection。对于LogicalConnection和（摘要）PhysicalConnection，需要具体的物理连接变体，如PhysicalConnectionX。（它实现了Class Table Inheritance。）此外，LogicalConnection需要一个新的Customer（简化：每次新订单的新客户）和Endpoint具体端点变体，如EndpointA（也是CTI实现）。数据模型左侧的表格只是基本数据，应该/不能更改。（当然更新甚至有点复杂，因为我必须检查每个相关对象，如果它已经存在，以避免例如为同一端点创建多个客户。）

我的第一个想法是像这样实现它：

转换输入，模型从表单中获取（我不使用Zend\Collection，因为我的结构完全不同于我的对象和数据库）;
为Order对象加水（已实施递归水合作用）;
为每种对象类型创建Mapper;
让每一个Mapper#save(...)
- 在它所依赖的对象的映射器上调用save(...);
- 然后只关心它的对象。

伪代码：

MyDataObjectA {
    $id;
    $myObjectB;
}

MyDataObjectB {
    $id;
}

MapperA {
    save($dataObjectA) {
        saving $dataObjectA
        calling MapperA#save($dataObjectA->getObjectB() )
    }
}

MapperB {
    save($dataObjectB) {
        saving $dataObjectB
    }
}

这是很多代码，每个案例都必须手动处理。（而且我不确定，但也许我可以在上下文相关的保存方面遇到一些问题，因为这种方法不会使上下文更加一致。）但是 - 我不相信，这是一个推荐的解决方案。

好吧，它可能是一个ORM。但是ZF2博客教程中的模型结构是什么？适用于这种情况吗？或者它只对非常简单的结构有用，而且几乎从不用于真实的应用程序？（然后我会问 - 我们是否真的需要这个教程，如果它显示了一种方法，几乎永远不能用于真正的应用程序？）或者我可能只是理解错误而且有更好的（高效，优雅等））方法？

如何在真实世界的应用程序中使用ZF2博客教程中的模型结构？

0 个答案: