0

n 層アーキテクチャがあります。

-データベースと通信し、すべてのビジネス ロジックを処理する WCF サービス。-WCF サービスと通信する ASP.NET MVC Web サイト。

これは、データベースから「ギター」の html ビューへのデータのシリアライズ/デシリアライズのシナリオです。

-Guitar_1 linq によって生成されたクラス、-Guitar_2 WCF サービスによって公開され、ASP.NET MVC Web サイトによって消費される DataContract。-Guitar_3 ビューに渡されたモデル

エンド ユーザーがギターを取得する場合、Guitar_1 は Guitar_2 に変換され、次に Guitar_3 に変換されます。それは実際には問題ではありませんが、エンド ユーザーがギターのリストを要求した場合、このすべてのプロセスがギターごとに繰り返されます (ループ)。

すべてのシリアライゼーションとデシリアライゼーションをプログラムで処理する必要がある場合、レイヤーごとに 1 つのクラスしかありませんでした。たとえば、Linq クラスで 'DataContract'/'DataMember' に注釈を付けることで、wcf プロジェクトでも実行できますが、データベース モデルを更新すると、すべての注釈が消えます (ASP.NET MVC プロジェクトでも同じケースで、サービスを更新します)。参照は、追加されたすべてのコードを削除します)。

また、これらの自動シリアライザーを使用する方が本当に生産的ですか? シリアライザー/デシリアライザーの作成にかかる時間は、クラス (DataContract/DataMember) に注釈を付け、クラス Guitar_1 から Guitar_2 への変換を処理するのと同じくらいの時間がかかります...それにパフォーマンスの損失 (ループと変換) を追加します...

皆さんはどう思いますか？このため、昔のようにコーディングしている人はいますか?

更新:「Abhijit Kadam」が示唆したように、Web サービスを使用するときに部分クラスを使用しましたが、Linq2SQL : POCO クラスを使用すると、より良い解決策が見つかりました。

4

1 に答える 1

2

フレームワークによって作成されたモデル クラスが自動的に再生成され、そのようなクラスの注釈が消去されるなどの変更が主な懸念事項である場合、この場合は部分クラスを使用できます。自動生成されたクラスが従業員の場合。次に、別のファイルで部分クラス Employee を作成し、注釈を付けるこの部分定義にフィールドを含めます。このクラスは、一掃されて再生されることはありません。ただし、コードをコンパイルすると、結果の Employee クラスは元の Employee クラス + 部分的に定義された Employee クラスの組み合わせになります。

クラス Guitar_1 から Guitar_2 への変換も問題なく、特定の要件を満たすためにそのようなことをしなければならない場合があります。JSON データは、WCF から MVC Web のようにネットワーク ワイヤ経由で転送されることを好みます。その後、ブラウザは MVC APP から json データを取得します。次に、jsrender やノックアウトなどのフレームワークを使用して、クライアント側 (ブラウザー) でデータを HTML としてレンダリングします。JSON は読みやすく、コンパクトで、JavaScript と JavaScript ライブラリは json が大好きです。

于 2012-06-10T15:20:52.647 に答える