我刚才发现有这种DTO模式.我怀疑是否
@H_502_1@它们很有用.
我的意思是,我应该将所有域对象映射到相应的DTO对象并将它们分配给查看域对象本身吗？那么,我会有很多具有相同上下文名称的类.
喜欢：
>用户(域对象),@H_502_1@> UserDTO,@H_502_1@> UserMapper或UserPersistenceFactory,@H_502_1@> UserFactory,@H_502_1@> UserSelectionFactory,@H_502_1@> UserUpdateFactory,@H_502_1@> UserAssembler(用于DTO映射),@H_502_1@> UserCollection,@H_502_1@> UserViewHelper(也许)
等等…
通常,DTO可以帮助您将数据库的数据问题与使用数据的对象的数据问题分开.您可以在DTO中放置验证,以确保特定成员遵循特定格式.通过这种方式,额外的代码不会使不关心数据库需要的对象变得混乱.
原文链接：https://www.f2er.com/php/133799.html此外,DTO在间接与数据库通信时变得强大.但是,这在可以自动生成DTO的语言中更为重要.
其中有DTO最强大和最引人注目的方面.它可以很容易地自动生成.在PHP中也是如此,但它需要额外的工具.
我明白为什么你可能想在PHP中使用它们,但是,我必须承认我自己还没有看到这样做的理由.通常,工厂对象足以满足大多数应用程序的需
然而
在具有不直接镜像数据库的对象的应用程序中,DTO再次获得授权.例如：具有由诸如地址和个人信息和信用卡等大量元信息组成的人员的应用程序可以将DTO用于所有单个数据,然后使用Person对象来处理该数据的所有使用.通过这种方式,交易可以直接通过信用卡DTO,没有麻烦,也没有大惊小怪.然后它可以从卡中访问所需的任何数据.但是,只要您想在该信用卡DTO上放置一个地址,您就不再拥有严格的DTO.
