タグ付けされた質問 「serialization」

DDDによると、ドメインロジックは、シリアル化、オブジェクトリレーショナルマッピングなどの技術的な問題で汚染されるべきではありません。 それでは、ゲッターとセッターを介して公開することなく、集計の状態をどのようにシリアル化またはマッピングしますか？リポジトリの実装など、多くの例を見てきましたが、実際にはすべて、マッピングのエンティティと値オブジェクトのパブリックアクセサーに依存していました。 リフレクションを使用してパブリックアクセサーを回避することもできますが、これらのドメインオブジェクトはIMOで暗黙的にシリアル化の問題に依存します。たとえば、シリアル化/マッピングの設定を調整しないと、プライベートフィールドの名前を変更したり削除したりできませんでした。そのため、代わりにドメインロジックに焦点を当てる必要があるシリアル化を検討する必要があります。 ここで従うべき最良の妥協点は何ですか？パブリックアクセサーと一緒に住んでいますが、マッピングコード以外には使用しないでください。または、明らかな何かを見逃しただけですか？ 私は、DDDドメインオブジェクト（エンティティと値オブジェクトで構成される集約）の状態をシリアル化することに明確に興味があります。これは、一般的なシリアル化や、ステートレスサービスが単純なデータコンテナオブジェクトで動作するトランザクションスクリプトシナリオではありません。

23 object-oriented  domain-driven-design  orm  serialization 

XMLまたはJSON（WCF）を提供できるREST Webサービスがあります。Protobufsを実装するというアイデアをいじっています。どうして？ 長所 サーバーの負荷が少ない。 メッセージサイズが小さい-トラフィックが少ない。 後で切り替えるよりも、すぐに切り替える方が簡単です。 短所 実装する必要がある デバッグ用のメッセージのトラブルシューティング/スニッフィングが難しくなります。 サーバーでGZipを有効にすると、JSONは同じ量のトラフィックを消費します これについてのあなたの提案や経験は何ですか？

23 web-services  wcf  serialization 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 4年前に閉鎖されました。 シリアル化は、Javaの永続化に使用されます。シリアル化を使用していくつかのオブジェクトを永続化してもかまいません。ただし、多数のオブジェクトの場合、ORM、データベースなどの方が適している場合があります。シリアル化は、小さなジョブにのみ役立つようです。私は間違っているかもしれません。それでは、非シリアル化方法よりもシリアル化の利点は何ですか？いつそれを使用し、いつそれを避けるべきですか？ この質問は、DZoneの記事Is Object Serialization Evil？を見て思い浮かびました。 そして、これらは私の質問を引き起こした行です： Javaとそのセッションオブジェクトを見ると、純粋なオブジェクトのシリアル化が使用されます。アプリケーションセッションの存続期間がかなり短い（最大で数時間）と仮定すると、オブジェクトのシリアル化は単純であり、十分にサポートされ、セッションのJavaコンセプトに組み込まれています。ただし、データの永続性が長期間（場合によっては数日または数週間）にわたり、アプリケーションの新しいリリースを心配する必要がある場合、シリアル化はすぐに悪になります。優れたJava開発者が知っているように、セッションでもオブジェクトをシリアル化する場合は、1Lだけでなく実際のシリアル化ID（serialVersionUID）が必要であり、Serializableインターフェイスを実装する必要があります。ただし、ほとんどの開発者は、Javaの逆シリアル化プロセスの背後にある実際のルールを知りません。オブジェクトが変更された場合、オブジェクトに単純なフィールドを追加するだけでなく、シリアライゼーションIDが変更されていなくても、Javaがオブジェクトを正しくデシリアライズできない可能性があります。突然、データを取得できなくなります。これは本質的に悪いことです。 さて、これを読んでいる開発者は、この問題のあるコードを決して書かないと言うかもしれません。それは本当かもしれませんが、あなたが使用しているライブラリや、あなたの会社に雇用されなくなった他の開発者はどうでしょうか？この問題が発生しないことを保証できますか？それを保証する唯一の方法は、異なるシリアル化方法を使用することです。

20 java  serialization 

JavaベースのサービスのGoogleプロトコルバッファーを評価しています（ただし、言語に依存しないパターンを期待しています）。2つの質問があります。 1つ目は、広く一般的な質問です。 人々が使用するパターンは何ですか？上記のパターンは、クラス編成（たとえば、.protoファイルごとのメッセージ、パッケージ化、および配布）およびメッセージ定義（たとえば、繰り返しフィールドと繰り返しカプセル化されたフィールド*）などに関連しています。 Google Protobufのヘルプページや公開ブログにはこの種の情報はほとんどありませんが、XMLなどの確立されたプロトコルに関する情報は大量にあります。 また、次の2つの異なるパターンに関する具体的な質問もあります。 .protoファイルでメッセージを表し、それらを個別のjarとしてパッケージ化し、サービスの消費者をターゲットに出荷します。これは基本的にはデフォルトのアプローチです。 同じことを行いますが、少なくともこれらの2つのメソッドをサポートするコントラクトを実装する各メッセージの周囲に、手作りのラッパー（サブクラスではありません！） ： public V toProtobufMessage() { V.Builder builder = V.newBuilder(); for (Item item : getItemList()) { builder.addItem(item); } return builder.setAmountPayable(getAmountPayable()). setShippingAddress(getShippingAddress()). build(); } public static T fromProtobufMessage(V message_) { return new T(message_.getShippingAddress(), message_.getItemList(), message_.getAmountPayable()); } 私はによって導入複雑さを離れて非表示にすることができますことを、私は（2）を参照の1つの利点はV.newBuilder().addField().build()、そのようにいくつかの意味のあるメソッドを追加しisOpenForTrade()たりisAddressInFreeDeliveryZone()など、私のラッパーに。（2）で見た2番目の利点は、クライアントが不変オブジェクト（ラッパークラスで強制できるもの）を処理することです。 （2）の欠点の1つは、コードを複製し、ラッパークラスを.protoファイルと同期する必要があることです。 誰かが2つのアプローチのいずれかについてより良い技術やさらなる批判を持っていますか？ *繰り返しフィールドをカプセル化するということは、次のようなメッセージを意味します。 message ItemList { repeated …

19 serialization  protobuf 

現在、C＃.NETアプリケーションのいくつかのモデルクラスの（再）設計段階にいます。（MVCのMのようなモデル）。モデルクラスには、適切に設計されたデータ、動作、および相互関係が十分にあります。モデルをPythonからC＃に書き換えています。 古いPythonモデルでは、いぼが見えると思います。各モデルはそれ自体をシリアル化する方法を知っており、シリアル化ロジックはクラスの残りの動作とは関係ありません。たとえば、想像してみてください： Image.toJPG(String filePath) .fromJPG(String filePath)メソッドを持つクラス ImageMetaData.toString()and .fromString(String serialized)メソッドを持つクラス。 これらのシリアル化メソッドがクラスの他の部分と密接に結びついていないことを想像できますが、クラスだけがそれ自体をシリアル化するのに十分なデータを知っていることが保証されます。 クラスが自分自身をシリアル化および逆シリアル化する方法を知ることは一般的な習慣ですか？または、一般的なパターンが欠落していますか？

16 c#  object-oriented  python  serialization 

より明確にするために、これは簡単な例です。 class A implements Serializable { public B b; } class B implements Serializable { public A a; } A a = new A(); B b = new B(); a.b = b; b.a = a; では、aオブジェクトとbオブジェクトをファイルにシリアル化し、そのファイルから逆シリアル化するとどうなりますか？ 4つのオブジェクト、それぞれ2つを取得すると思った。同一のオブジェクトですが、異なるインスタンス。 しかし、他に何かあるのか、それとも正しいのか間違っているのかはわかりません。 答える必要のある技術がある場合は、Javaに基づいて考えてください。 ありがとうございました。

15 java  serialization 

さまざまなサービスを通じてメッセージを処理します（1つのメッセージは、完了する前におそらく9つのサービスに触れ、それぞれが特定のIO関連機能を実行します）。現在、パフォーマンスに関して最悪のケース（XMLデータコントラクトシリアル化）とベストケース（メモリ内MSMQ）の組み合わせがあります。 メッセージの性質は、シリアル化されたデータが約12〜15キロバイトになり、週に約400万のメッセージを処理することを意味します。MSMQの永続メッセージは私たちにとって遅すぎました。データが大きくなるにつれて、MSMQのメモリマップファイルからのプレッシャーを感じています。 サーバーのメモリ使用量は16 GBで、キューイングのためだけに増加しています。 メモリの使用量が多い場合、マシンがスワップを開始するため、パフォーマンスも低下します。既にMSMQの自己クリーンアップ動作を実行しています。 ここで間違っている部分があるように感じます。RavenDBを使用してメッセージを永続化し、識別子をキューに入れようとしましたが、パフォーマンスは非常に遅くなりました（せいぜい毎分1000メッセージ）。それが開発バージョンを使用した結果なのかどうかはわかりませんが、より高いスループットが必要です[1]。コンセプトは理論上は非常にうまく機能しましたが、パフォーマンスはタスクに応じていませんでした。 使用パターンには、すべての読み取りを行うルーターとして機能する1つのサービスがあります。他のサービスは、サードパーティのフックに基づいて情報を添付し、ルーターに送り返します。ほとんどのオブジェクトは9〜12回タッチされますが、約10％は、サードパーティが適切に応答するまで、このシステムでしばらくループすることを強制されます。この理由でメッセージの優先度フィールドを使用するため、サービスは現在これを考慮しており、適切なスリープ動作を持っています。 だから、私の質問は、C＃/ Windows環境でディスクリートだがLAN接続されたマシン間でメッセージを渡すための理想的なスタックは何ですか？ 通常、XMLシリアル化ではなくBinaryFormatterから始めますが、シリアル化をドキュメントストアにオフロードするのがより良い方法である場合、それはうさぎの穴です。したがって、私の質問。 [1]：私たちのビジネスの性質は、メッセージをより早く処理するほど、より多くのお金を稼ぐことを意味します。週の後半にメッセージを処理すると、そのお金を稼ぐ可能性が低くなることを経験的に証明しています。「1分あたり1000」というパフォーマンスは非常に高速に聞こえますが、実際にはその数が10k /分以上必要です。1週間あたりのメッセージ数を指定しているからといって、それらのメッセージを処理するのに1週間あるというわけではありません。 ===============編集： 追加情報 コメントに基づいて、いくつかの説明を追加します。 シリアル化がボトルネックであるかどうかはわかりません。アプリケーションのベンチマークを行ったところ、シリアル化はヒートグラフに表示されますが、サービスのCPU使用率の2.5〜3％にしか関与していません。 私は、私たちのメッセージの永続性とMSMQの潜在的な誤用についてほとんど心配しています。キューのパフォーマンスを維持できるように、非トランザクション、非永続メッセージを使用していますが、少なくとも永続メッセージが再起動後も存続できるようにしたいです。 RAMを追加することは一時的な対策です。マシンはすでに4GBから16GBのRAMに移行しており、追加を続けるためにマシンを停止することはますます難しくなっています。 アプリケーションのスタールーティングパターンにより、オブジェクトがポップされてからキューにプッシュされる時間の半分は、まったく変化しません。これは、他の場所の何らかのキー値ストアにそれを保存し、メッセージ識別子を単に渡すことに再び役立ちます（IMO）。 スタールーティングパターンはアプリケーションに不可欠であり、変更されません。途中のすべてのピースが非同期に（ポーリング方式で）動作し、再試行動作を1か所に集中させたいため、アプリケーションをムカデにすることはできません。 アプリケーションロジックはC＃で記述され、オブジェクトは不変のPOCO、ターゲット展開環境はWindows Server 2012です。特定のソフトウェアがLinuxでのみサポートされている場合、追加のマシンを立ち上げることができます。 私の目標は、現在のスループットを維持しながら、最小限の資本でメモリフットプリントを削減し、フォールトトレランスを向上させることです。

13 serialization  queueing 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 6年前に閉鎖されました。 Javaで書かれた大規模なユーザー向けWebサイトの開発に興味があります。 設計に関しては、メインのWebアプリケーションに対するデータプロバイダーとして機能できる、独立したモジュラーサービスの開発を考えています。 これらのモジュラーサービス（データプロバイダー）の作成については、Springなどの既存のフレームワークを活用し、RESTfulデザインパターンに従ってこれらのサービスを開発し、JSONなどのメッセージ形式でHTTPを介してリソースを公開するか、既存のネットワークを活用できますNetty（http://netty.io/）のようなフレームワークとProtobufs（https://developers.google.com/protocol-buffers/docs/overview）のようなシリアル化形式、およびシリアル化されたprotobuf を送受信するTCPサーバーを開発するペイロード。 どちらを選択するかはいつですか？Protobufsのようなシリアル化形式を使用して、ワイヤを介してバイトストリームを送信する利点はありますか？JSONを使用するだけでオーバーヘッドが発生しますか？TCP / IPを使用してからHTTPを使用するまでのオーバーヘッドはどれくらいですか？そのようなサービスを構築するためにSpring over Nettyをいつ使用する必要がありますか？

13 java  rest  http  serialization  tcp 

簡単な質問：C＃でのシリアル化にはデフォルトのコンストラクターが必要であることを理解しています。これは、コンストラクターで注入されたDIを使用する可能性を排除します（これは、私の読みでは、一般的に好ましいスタイルのDI です[引用が必要]）。それは本当にどちらか一方の状況ですか、それとも何か不足していますか？ （サイド質問）：IoCコンテナーはこのトレードオフをどうにかして回避しますか？

9 dependency-injection  serialization 

C＃でシリアル化されたオブジェクトを格納および維持するためのベストプラクティスは何ですか？適用できる戦略やパターンはありますか？ 私がこれまで信じてきたのはこれです： スペースと速度の両方の点でXMLよりもJsonを優先しますが、大きなデータセットの場合、XMLはLINQ to XMLを介してデータをクエリ/マイニングする方が簡単です。 すべてのプロパティについて、シリアル化された名前に明示的にマップします。将来、プロパティの名前を変更する必要がある場合、シリアル化されたデータは壊れません。属性はこれに役立ちます。 将来データを大量に移行する必要がある場合に備えて、シリアル化されたオブジェクトにある種のバージョン情報を保存します 更新：（難しい方法を見つけた） アプリケーション全体およびすべてのバージョンで、すべての日時を統一された方法で保存します。フォーマットとタイムゾーンの両方について。

8 c#  patterns-and-practices  serialization