プレゼンテーションモデルをどこで変換するのか

プレゼンテーションモデルとドメインモデルをどこで変換したらよいのかは難しい問題です。私は、ビジネスロジック層で変換したほうが良いと考えていますが、その理由は2つあります。
1つは、チームに必要とされる知識と開発者のレベルです。
一般にプレゼンテーション層とビジネスロジック層でチーム(or 開発者)を分ける場合、ビジネスロジック層には、業務に精通している人を置き、プレゼンテーション層には、比較的初心者を置いて、業務は分からなくてもとりあえず、Webのフレームワークの使い方が分かればOKのような人の配置をすることが多いのではないかと思います。
そのときに、モデルの変換をプレゼンテーション層でやることにすると、プレゼンテーション層の人は、ドメインモデル(業務)の知識もなくてはならないことになり、想定される役割分担と一致しません。
モデルの変換は、ビジネスロジック層に任せることにより、プレゼンテーション層の役割をできるだけ簡単にして、比較的初心者でも作業を行えるようにしたほうがチームとしてうまくいきます。業務に精通している人が、プレゼンテーションモデルとドメインモデルの変換を行うのはさほど難しいことではありません。
2つめは、O/R Mapperのlazy loading問題です。
ドメインモデルは、関連がネストする(AがBに依存し、BがCに依存し、CがDに...)ことが多く、最初にすべての関連データをロード(フェッチ)することができないので、lazy loadingのテクニックが使われます。
http://d.hatena.ne.jp/higayasuo/20050817#1124260949の補足参照。
このlazy loadingの時にSQL文が暗黙に実行される場合があるのです。
SELECT文とはいえ、プレゼンテーション層でSQLが実行されるのは、望ましくありません。トランザクション処理として、ビジネスロジック層で実行されるべきです。
HibernateでOpenSessionInViewというプレゼンテーション層でSQL文を発行しても何とかエラーにしないようにするというテクニックがありますが、役割分担が明確でなく、使用すべきではないと思います。
という2つの理由から、ビジネスロジック層で、モデルの変換を行うことを推奨しています。