私はいつも "全脂肪"あなたがそれをダビングしたように、DTOアプローチ。パフォーマンスは機能であり、不必要なネットワーク遅延を追加するよりもパフォーマンスを低下させる良い方法はありません。
サーバーとの往復の回数を減らすという利点のために、ひどくリソースの詰まったマシンを扱っているのでなければ、フル・ファットになるよりも、
多くの情報はありませんでしたが、ここではDBテーブルを使用していると思いますか？もしそうなら、私は個々のDBレコードの純粋な表現（明らかに機密フィールドを省略）として「エンティティ」を公開することを好む。それを公開してナビゲートするためのRESTful APIを作成します。
EDIT：私は「全脂肪」によって何を意味するかについていくつかのコードを詳述すると（注： 特定の余分な詳細は、冗長性を減らすために省略されています）。
例SQLセットアップ：
create table dbo.User (
Id int identity primary key,
Name nvarchar(50)
);
create table dbo.Post (
Id int identity primary key,
UserId int not null foreign key references dbo.User(Id),
Title nvarchar(50),
Body nvarchar(max)
);
例CLRオブジェクト：
public sealed class User
{
public int Id { get; set; }
public string Name { get; set; }
public IEnumerable<Post> Posts { get; set; }
}
public sealed class Post
{
public int Id { get; set; }
public int UserId { get; set; }
public string Title { get; set; }
public string Body { get; set; }
public User User { get; set; }
}
上記セットアップ、オブジェクトを公開する方法の例を考えるとRESTfulに希望次のようになります。
/api/users /*users collection*/
/api/users/1 /*user resource*/
/api/users/1/posts /*user resource with posts sub-collection*/
/api/posts /*posts collection*/
/api/posts/1?user=1|0 /*post resource with/without User*/
これは現在の形。銀色の弾丸はありません。答えは「それは依存する」です。あなたが必要としているものと実行可能なオプションが分かっているだけです。 – CodeCaster