对象工厂问题——利用数据库查询信息创建对象
我有几个对象，例如产品、订单等。当我从数据库中获取信息时，我会获取一行并创建其中一种类型的对象。然后我使用创建的对象。我读到这叫做工厂。
这样做有什么好处吗？尤其是像 PHP 这样的松散类型语言？
谢谢
编辑：这是我获得数据库不可知性的地方吗？这就是 ORM 本质上做的事情吗？
I have several objects, like products, order, etc. When I get information from my database I take a row and create one of the types of objects. I then work with that object created. I read this is called a factory.
Is there some advantage to doing this? Especially in a loosely typed language like PHP?
Thanks
edit: is this where I get database agnosticity? Is this what an ORM essentially does?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
通过从数据库查询创建对象，您可以定义对象和关系数据库之间的映射。这正是 ORM 软件的作用。
通过这样做并确保您的对象从不直接访问数据库，而是使用数据库访问函数/对象，您可以通过两种方式保护您的代码免受更改：
对数据库架构的更改不会影响您的代码。相反，代码更改将仅位于您的数据库访问对象中。
您可以通过实现遵循与原始接口相同的接口的新数据库层来切换到不同的 DBMS。您的其他对象不需要更改。
我想从这个意义上说，您获得了一些数据库不可知性，但是使用提供开箱即用的不可知性的数据库库可能会更好。
在我看来，优点是您正在使用对象并获得面向对象语言提供的所有优点。然后，您可以在更高级别（根据您定义的对象）读取域逻辑，而无需筛选数据库查询。自己编写 ORM 可能很困难，但是有一些工具可以帮助您做到这一点。
这是我通常采取的路线，但我不进行任何 PHP 开发，所以我不能说它有多适用于该语言。
By creating your objects from the database queries, you are defining the mapping between your objects and the relational database. This is exactly what ORM software does.
By doing so and ensuring that your objects never directly access the database, but instead use your database-access functions/objects, you are protecting your code from changes in two ways:
Changes to your database schema will not ripple through your code. Instead, the code changes will be located only in your database access objects.
You can switch to a different DBMS by implementing a new database layer that follows the same interface as the original. Your other objects will not require changes.
I guess in that sense, you gain some database-agnosticity, but you'll probably be better off using a database library that provides that agnosticity out of the box.
In my opinion, the advantage is you are working with objects and gain all of the advantages that an object-oriented language offers. You can then read the domain logic at a higher level (in terms of the objects you have defined) without sifting through database queries. Writing the ORM yourself can be tough, but there are tools out there that help with that.
This is the route I normally take, but I don't do any PHP development, so I can't say how well it applies to that language.
您所描述的是数据访问层的实现 - 它听起来不像 Factory 的示例方法模式，也不是抽象工厂模式。
是的，ORM 弥合了从对象到关系数据库的差距，并且可以充当您的数据访问层。请记住，您使用的任何 ORM 都有一定的优点/缺点/限制。根据您的经验和要求，编写自己的数据访问层有时是一个好主意；不觉得你必须使用第 3 方 ORM。
是的，良好的数据访问层可以轻松更换存储机制（不同的数据库、XML、平面文件等），而无需更改业务逻辑、UI 或其他代码。
无论是松类型语言还是强类型语言，如果您使用 OO 语言，那么使用数据对象（由 ORM 或自行开发的数据访问层提供）编写代码会容易得多。我确信可以编写一个没有数据访问层的系统，其中业务层直接与数据库一起工作。但实施和维护可能会更具挑战性。
What you're describing is an implementation of a Data Access Layer - it doesn't sound like an example of the Factory Method pattern, nor the Abstract Factory pattern.
Yes, ORMs bridge the gap from objects to relational databases, and can serve as your Data Access Layer. Bear in mind, any ORM you use has certain pros/cons/limitations. Depending on your experience and requirements, writing your own data access layer is sometimes a good idea; don't feel like you HAVE to use a 3rd-party ORM.
Yes, a good data access layer makes it easy to swap out your storage mechanism (different database, XML, flat files, whatever) without changing your business logic, UI, or other code.
Regardless of loose-typed or strong-typed languages, if you're working in an OO language, it will be much easier to write code using data objects (provided by an ORM or homegrown data access layer). I'm sure it's possible to write a system with no data access layer, where your business layer works directly with the database. But it will likely be more challenging to implement and maintain.