7

さて、この DTO パターンがあることがわかりました。それらが役に立つかどうか疑問に思います。

つまり、すべてのドメイン オブジェクトを対応する DTO オブジェクトにマップし、それらをドメイン オブジェクト自体の代わりにビューに割り当てる必要があるのでしょうか? その場合、同じコンテキスト名を持つクラスがたくさんあります。

お気に入り：

  • ユーザー（ドメインオブジェクト）、
  • ユーザーDTO、
  • UserMapper または UserPersistenceFactory、
  • ユーザーファクトリー、
  • ユーザー選択ファクトリー、
  • ユーザーアップデートファクトリー、
  • UserAssembler (DTO マッピング用)、
  • ユーザーコレクション、
  • UserViewHelper(たぶん)

等...

4

1 に答える 1

3

通常、DTO は、データベースのデータの問題を、データを利用するオブジェクトのデータの問題から分離するのに役立ちます。DTO に検証を配置して、特定のメンバーが特定の形式に従っていることを確認できます。このようにして、その余分なコードは、データベースが何を必要としているかを気にしないオブジェクトを混乱させません。

さらに、DTO は、データベースと間接的に対話する場合に強力になります。ただし、これは、DTO を自動生成できる言語ではより重要です。

そこに、DTO の最も強力で説得力のある側面があります。簡単に自動生成できること。これは PHP にも当てはまりますが、追加のツールが必要です。

PHP でそれらを使用したい理由は理解できますが、そうする理由はまだわかりません。通常、ほとんどのアプリケーションでは Factory + Object で十分です。

でも

データベースを直接ミラーリングしないオブジェクトを持つアプリケーションでは、DTO が再び権限を与えられます。たとえば、住所、個人情報、クレジット カードなどの多くのメタ情報で構成された People を持つアプリケーションでは、すべての個人データに DTO を使用し、Person オブジェクトを使用してそのデータのすべての使用を処理できます。このようにして、Transaction はクレジット カード DTO に直接渡すことができます。その後、カードから必要なデータにアクセスできます。ただし、そのクレジット カードの DTO にアドレスを追加したい場合は、厳密な DTO は使用できなくなります。

于 2010-12-28T20:09:38.170 に答える