使用 Doctrine for PHP 的优点？
刚刚遇到 Doctrine 项目，它有一个对象关系映射器和一个数据库抽象层。 Doctrine 提供了哪些其他 PHP 抽象层没有提供的功能？除了通过用 Doctrine 查询语言编写的查询来获取对象之外，ORM 还能有什么实际用途呢？您真的想用这种查询语言来开发整个 Web 应用程序吗？表现好吗？
总的来说，在 Doctrine 上构建应用程序是否更容易维护和理解？它是否过度设计，并且构建在适合中小型项目的抽象层上吗？ （<50 个 GUI 屏幕），而不是直接使用 MySQL。
Just came across the Doctrine Project which has an Object Relational Mapper and a DB Abstraction Layer. What does Doctrine provide that other PHP abstraction layers don't? And what practical use can you put the ORM to, apart from fetching objects via queries written in Doctrine Query Language? Is the query language really something you want to develop an entire web app in? Does it perform well?
On the whole does building an app on Doctrine make it easier to maintain and understand? Is it over-engineered, and is building on an abstraction layer sensible for small-medium size projects? (<50 GUI screens), as opposed to directly working with MySQL.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
只有负责维护业务对象的应用程序的一部分应该知道 Doctrine 的存在。这部分不一定是 100% 基于教义的。
确实。代码更容易阅读、理解和维护。
事实上，教义的基本原理非常简单。对于小型、中型甚至一些大型应用程序来说，这是一个非常好的选择。
教义并不能解决所有问题，有时还存在一些问题。然而对于典型的任务来说它非常有用。恕我直言，这是目前 PHP 最好的 ORM/ODM。
Just a part of the application responsible for maintaining business-objects should be aware of the existence of Doctrine. And that part doesn't have to be 100% Doctrine-based.
Definitely. The code is easier to read, understand and maintain.
Actually Doctrine is quite simple in its fundamentals. And it's a very good choice for small, medium and even some large applications.
Doctrine isn't the answer for everything and sometimes it's a little problematic. However for typical tasks it's extremely useful. IMHO the best ORM/ODM for PHP at this moment.
我想对克罗津的回答补充几点，但遗憾的是无法发表评论。它们是：
恕我直言，目前 Doctrine 提供了所有可用 php ORM 中最好的 IDE 代码完成支持和数据库层抽象。它没有过度设计并遵循坚实的原则。
I'd like to add a few points to Crozin's answer, but unfortunately can't comment it. Here they are:
IMHO at the moment doctrine provides best IDE code completion support and DB layer abstraction among all php ORMs available. It is not over-engineered and follows SOLID principles.
我想对 GerKirill 的回答补充一点。恕我直言，缺乏对魔法 getter/setter 方法的支持是一个弱点，而不是一个优点。如果您曾经滚动浏览过几十页相同的 getter/setter，您会意识到这些方法是对空间的巨大浪费（更不用说编译时间了）。没有人会意外地设置对象变量，并且 setter 不会阻止您这样做......当您想要更改属性时，您只需调用 setter（setter 如何“保护”属性 - 如果您是如果你会犯一个错字并直接设置错误的属性值，你也会犯同样的错字并调用错误的setter）。除了获取或设置属性之外，setter 或 getter 很少做任何事情。如果您必须执行一些特殊操作来设置或获取属性，则该属性应该是一个方法（请参阅 http://www.yegor256.com/2014/09/16/getters-and-setters-are-evil.html），否则你应该重构您的代码，或者您应该调用属性验证函数（通常在创建对象时）。这是困扰面向对象世界的无可争议的真理之一。在发布标准的公认回复之前请考虑一下。
I'd like to add a point to GerKirill's answer. The absence of support for magic getter/setter methods is a weakness, IMHO, not a strength. If you've ever scrolled through dozens of pages of identical getters/setters, you will realize that these methods are a huge waste of space (not to mention compile time). No-one accidentally sets an object variable, and a setter does not prevent you from doing that ... when you want to change the property, you just call the setter (how does a setter "protect" the property -- if you are going to make a typo and directly set the wrong property value, you will make the same typo and call the wrong setter). And it is very rare for a setter or getter to do anything other than get or set a property. If you have to do something special to set or get a property, that property should be a method (see http://www.yegor256.com/2014/09/16/getters-and-setters-are-evil.html), or you should be refactoring your code, or you should be calling a property validation function (generally at the time the object is created). This is one of those un-challenged truisms that plague the OO world. Think about it before you post the standard received-wisdom reply.