PHP 中的数据传输对象，许多具有相同上下文名称的类
好吧，我刚刚发现有这种 DTO 模式。我想知道是否 它们很有用。
我的意思是，我是否应该将所有域对象映射到其相应的 DTO 对象并将它们分配给视图而不是域对象本身？那么，我会有很多具有相同上下文名称的类。
像：
- User（域对象），
- UserDTO，
- UserMapper或UserPersistenceFactory，
- UserFactory，
- UserSelectionFactory，
- UserUpdateFactory，
- UserAssembler（用于DTO映射），
- UserCollection，
- UserViewHelper（可能）
等...
Well I just figured out that there's this DTO pattern. I wonder if
they are useful.
I mean, should I map all my domain objects to their corresponding DTO objects and assign them to view instead to the domain objects themselves? I would, then, have a lot of classes with the same contextual name.
Like:
- User(Domain Object),
- UserDTO,
- UserMapper or UserPersistenceFactory,
- UserFactory,
- UserSelectionFactory,
- UserUpdateFactory,
- UserAssembler(for DTO mapping),
- UserCollection,
- UserViewHelper(maybe)
etc...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
通常，DTO 可以帮助您将数据库的数据关注点与使用该数据的对象的数据关注点分开。您可以在 DTO 中进行验证，以确保特定成员遵循特定格式。这样，额外的代码就不会弄乱那些不关心数据库需要什么的对象。
此外，当间接与数据库对话时，DTO 会变得非常强大。然而，这对于可以自动生成 DTO 的语言来说更为重要。
这就是 DTO 最强大、最引人注目的方面。它可以轻松自动生成。在 PHP 中也是如此，但它需要额外的工具。
我明白为什么您可能想在 PHP 中使用它们，但是，我必须承认我自己还没有找到这样做的理由。通常，工厂 + 对象对于大多数应用程序来说就足够了。
然而，
在具有不直接镜像数据库的对象的应用程序中，DTO 再次被授权。例如：具有由大量元信息（如地址、个人信息和信用卡）组成的 People 的应用程序可以对所有个人数据使用 DTO，然后使用 Person 对象来处理该数据的所有使用。这样，交易就可以直接通过信用卡 DTO，没有任何麻烦。然后它可以从卡中访问所需的任何数据。但是，一旦您想在信用卡 DTO 上添加地址，您就不再拥有严格的 DTO。
Typically a DTO can help you separate the data concerns of the database from the data concerns of the objects that make use of the data. You can place validation in the DTO to ensure that a particular member follows a specific format. In this way, that extra code doesn't clutter up the objects which don't care what the database needs.
Additionally, DTO become powerful when talking to a database indirectly. However, this is of much more importance in languages that can auto-generate DTOs.
Therein is the most powerful and compelling aspect of the DTO. That it can be auto-generated easily. This is also true in PHP, however it requires additional tools.
I see why you might want to use them in PHP, however, I must admit I've yet to see a reason to do so myself. Typically a Factory + Object is enough for most applications.
HOWEVER
In an application that has objects that don't mirror the database directly, a DTO becomes empowered again. For example: an application that has People who are comprised of lots of meta information like Addresses and Personal Info and Credit Cards, could use DTOs for all the individual data, then use a Person object to handle all the usage of that data. In this way, a Transaction could be passed the Credit Card DTO directly, with no muss and no fuss. It could then access whatever data it needs to from the card. However, as soon as you want to put an Address on that Credit Card DTO, you no longer have a strict DTO.