繰り返し項目の実装はDtoとEntityのどちらを使うべきか？ - 出羽ブログ
『複数レコード処理（繰り返し）』の場合に、Entityをそのまま使うというのに違和感を感じてしまうのですが、そんな感覚にはこだわらない方が良いのでしょうか。 導出項目を得るような処理というのはプレゼンテーションロジックなのだから、DTOに値をコピーして、DTOのgetterで実装するようにした方が良いような気がしてしまっているのですが。 私の以前のエントリでは、繰り返し更新がなければDtoのではなく、Entityを積極的に使うことを書きました。でもDtoを使うケースでも特に問題ないと思います。ただし、メリット・デメリットは、把握しておいた方がいいと思います。 【メリット】 繰り返し処理には、常にDtoを使うため、設計に一貫性がでる。実装者も迷わない。 【デメリット】 プレゼンテーションモデル側で導出項目のロジックを用意すると重複しやすい。 繰り返し更新が必要となるケースは比較的少ない状況に
第24回 アプリケーション設計と標準化（前編）
今回と次回はWebシステム基盤ではなく，その上で動作させるアプリケーションの設計について取り上げます。一般にWebシステム基盤の設計者（Webアーキテクト）とアプリケーションの設計者（アプリケーションSE）は別な担当者であることが多いのですが，アプリケーションはWebシステム基盤と整合性を取っていなければ正しく動きません。整合性を取るために，WebアーキテクトはアプリケーションSEの設計作業を支援することが不可欠で，設計支援するにはアプリケーション設計の知識が必要になります。 アプリケーション設計のポイントは，「アプリケーション・アーキテクチャ」と「アプリケーションの標準化」です。この2点に重点を置いて説明します。 アプリケーション・アーキテクチャ システム全体を見て描いたアプリケーションの青写真を「アプリケーション・アーキテクチャ」と呼びます。アプリケーションを設計する際には，システム基
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
