1

SPA (シングル ページ アプリケーション) の作成に関する多くのチュートリアルを見てきましたが、それらの多くは、自動化されたデータ サービス レイヤーを取得するために、breezejs や jaydatajs などの外部ライブラリを使用しています。

これらのライブラリは、クエリ可能な IQueryable オブジェクトを公開することを期待しています。

私の質問は、サーバーから IQueryable を公開するリスクは何ですか? これらのjsライブラリでこのショートカットを作成する価値があるかどうか、またはサーバーで独自の関数を公開し、クライアントでデータサービスを自分で実装する必要があるかどうかを知りたいです。

問題は、Iqueryable を公開するとき、たとえば、breastjs を使用して、linq のような構文でフィルタリングとページングのためのクエリを作成できることです。使用しない場合は、これらの関数をサーバーにフィルタリングおよびページング用に実装する必要があります。それらへの呼び出しをJavaScriptで実装します。

私が明確だったことを願っています:-)

4

2 に答える 2

5

IQueryable を公開するときに私がやろうとしていることが 1 つあります... EF スタイル オブジェクトを公開しないようにしてください。常に、制御できる上にある種のビュー モデルがあることを確認してください。

例として、DB に User と UserSecrets があるとします。

public class User
{
    public long UserId { get; set; }
    public string Name { get; set; }
    public virtual ICollection<UserSecret> UserSecrets { get; set; }
}

public class UserSecret
{
    public long UserSecretId { get; set; }
    public long UserId { get; set; }
    public string Secret { get; set; }
}

公開するIQueryable<User>と、UserSecrets も簡単に抽出できます

www.blah.com/users?$expand=UserSecrets

代わりに、UserViewModelまたは類似のものを公開します

public class UserViewModel
{
     public string Name { get; set; }
}

IQueryable<UserViewModel>次の方法で公開できます。

return dbContext.Users.Select(u => new UserViewModel { Name = u.Name })

素晴らしいことは、これがまだ残っているということですIQueryable- フィルタリングなどは引き続き可能で、db レベルで実行されますが、プルできるデータを正確に制御できます (この場合UserSecretはアクセスできなくなります)。

もちろん、独自のフィルターを適用して、許可されていないデータにユーザーがアクセスできないようにすることもできます。

return dbContext.Users.Where(u => ...).Select(u => new UserViewModel { Name = u.Name })
于 2013-04-02T11:43:46.687 に答える
0

エンティティ オブジェクトを投影するための DTO オブジェクトを作成し、この DTO で必須のプロパティを作成しようとしていることがわかります。このアクションにより、データベースから公開される独自の情報を保護し、サービス側からクライアントへの秘密情報の漏えいを回避できます。

于 2013-04-04T01:54:09.210 に答える