我正在将一个相当大（但有些简单）的应用程序从 Symfony 转换为 Zend，因为 DB 很大。这也是我的第一个 Zend 项目，但目前看来进展顺利。该应用程序很简单，数据库相当复杂（我预计如果手动完成，数据映射将提前数小时）。
我拥有使用 Symfony FW 完成的所有原始源代码。原版使用 propel 并且可以工作（并且有 200 多个模型映射 DB，快速浏览一下 272 个）。
我的数据库表逐行依赖，我也在重用原始数据库结构...直接导入表/模式，所以我想原来的推进在这方面仍然可以正常工作。
我的问题是，是否值得花时间尝试使用基于 Zend 的新应用程序版本重用旧应用程序的推进部分？这应该是直截了当的冒险吗？
如果这可行，它可能会从我的生活中消除许多不眠之夜:)
【问题讨论】：
标签： database zend-framework orm symfony1 propel
为了其他可能看到这里的人的利益，我将回答我自己的问题......
我最终做的是安装最新版本的 Propel (1.5)。 Jan Fabry（上图）提到之前生成的模型（来自 SF 项目）可能存在残留元素，这也是我的担忧。所以我在数据库上运行了一个“反向”并生成了新的模式/模型。
我肯定会保留原始生成的模型以供参考，因为我正在重用现有数据库。我还在之前的应用程序上运行了一个 phpDoc 构建，包括生成的 Propel 模型，这是一个很好的工具，可以查看之前所做的事情。作为一个“侧面”提示，我还在我新生成的模型上运行了 phpDoc，现在我有一种“参考”文档，可以指向从 Propel 构建生成的新“自定义 db api”……真的很酷！ 已经存在一些架构问题，例如缺乏对 ENUM 类型的支持……但是在 Propel 的 v1.6 中出现。原始模型作为 Propel 如何与现有数据库一起使用的工作示例。当问题出现时，我预计会“手动”编辑新架构中的一些条目。
Propel v1.5 有一个新的“查询”API（由 Frosty Z 指出），它正在替换（或增强）我的新应用程序中的“标准”和“同行”。原始代码仍然可以作为一个很好的模型（不是 MVC 模型）来说明数据库之前如何集成到应用程序的逻辑中，但我发现新版本的 Propels 'query' API 将有很大帮助。
我读到 Propel 在某处不支持“加入”，但我看到这个版本支持，并且 Propel 中还有许多其他新的和有用的功能。值得注意的是，新 API 处理关系的方式。这一切都在 Propel 的文档中，我很想使用它。对于“手动”界面而言，数据库有点大且复杂，因此 Propel 的“反向”功能也非常方便。
这样的查询：
$Users = UsersQuery::create()
->filterByLastName($LastName)
->find(); // $Users is a PropelCollection object
return $Users;
正如 Frosty Z 所说，它非常“好”，与使用 Zend_Db 或直接 PHP/MySQL 相比，节省了大量编码，并且似乎比以前的“标准”、“对等”方式更简单。那 sn-p 来自 Propel Docs，解决了让我在别处寻找解决方案的问题，有条件的发现似乎它的代码量会相对增长。而且我已经可以看到根据 ACL 过滤结果是多么容易。
我的回答是解释为什么我不重新使用原始模型；缺乏新方法和担心可能导致错误或头痛的残留代码，以及我坚持使用 Propel 的原因（除了它看起来真的很好的事实）；我有一个工作 ORM 的现有示例。真的，我可以说以上两个答案都是我所接受的。谢谢大家！
【讨论】：
模型类可以包含对 Symfony 类的引用，例如 sfMixer。它们由extra Propel behaviors in the Symfony distribution 添加。因为sfMixer 可能不会存在于您的新 Zend 项目中，这可能会导致错误。
但是，应该可以使用干净的 Propel 安装重新生成模型（在 Zend 中，或在禁用额外行为的 Symfony 中），然后将您自己的用户可编辑类文件复制到空生成的类文件上。
如果您在 Zend 项目中使用与在 Symfony 项目中相同的 Propel 版本，这应该可以直接使用（除非您编辑了 Base 类，但我假设您没有这样做）。如果您在 Zend 中使用更新版本的 Propel 来生成模型，那么如果您访问 protected 成员之后可能会出现兼容性问题。
【讨论】：
我认为您可以重用旧应用程序的 Propel 部分，因为 Propel 1.5（当前稳定版）和下一个 1.6 向后兼容到 Propel 1.3（如果我没记错的话，Symfony 1.0 使用）及其原始“标准” " 语法。
您将受益于 Propel 1.5 的改进（其中包括漂亮的“查询”语法），而不会丢失现有代码。
见：
【讨论】：