3

私は、バックエンドデータベースを使用して更新したアプリケーションに数年間取り組んできました。重要なのは、すべてがクライアントにキャッシュされるため、動作するためにネットワーク接続が必要になることはありませんが、接続がある場合は常に最新の更新を取得します。更新されたすべてのアプリケーションには最新バージョンのデータベースが付属しており、データベースが更新されたときに最小限のデータのみをダウンロードするようにしたかったのです。

現在、タイムスタンプ付きのテーブルを使用して更新を確認しています。こんな感じです。

ID - Name - Description- Severity - LastUpdated
0 - test.exe - KnownVirus - Critical - 2009-09-11 13:38
1 - test2.exe - Firewall - None - 2009-09-12 14:38

このアプローチは、以前必要だったものには問題ありませんでしたが、このタイプの動的アプローチを使用するために、アプリケーションの機能をさらに拡張することを検討しています。現在、すべてのデータはとして保存されてXMLいますが、完全なXMLファイルをデータベースに保存せず、変更されたデータのみを送信したいと思います。

では、動的コンテンツ（text / xml / json / xaml）をデータベースに保存するための非常に単純なアプローチを許可し、クライアントに新しい更新のみをダウンロードさせるにはどうすればよいでしょうか。XMLを直接処理できるロジックを挿入することを考えていました

ID - Data - Revision
15 - XXX - 15

XXXのようなもの<Content><File>Test.dll<File/><Description>New DLL to load.</Description></Content>で、キャッシュに挿入されますが、順番にロードする必要があるため、これは明らかに複雑になります。

言及されている別のアプローチは、ソース管理に似たものに基づいて、ファイルのルートにバージョンを保存し、デルタを計算して、クライアントに送信する必要のあるデータの最小量を計算することでした。

データ破壊のリスクなしにこれに取り組む方法について誰かが提案を得ましたか？また、おそらく悪いリビジョンを元に戻して、それらを新しい動作するリビジョンに置き換えることができる機能で拡張したいと思います。

4

4 に答える 4

4

私はあなたが説明したのとほぼ同じようにアプリケーションを構築しました。DjSolが言及したMicrosoftSyncFrameworkの上に構築しました。

SqlCeデータベースを備えたC＃フロントエンドアプリケーションを使用し、もう一方の端にSQL2005Serverを使用しています。

次の記事は私にとって非常に役に立ちました。

チュートリアル：SQLServerとSQLServerCompactの同期

ウォークスルー：同期サービスの作成

ADO.NET2.0の同期サービスの段階的なN層構成

同期フレームワークを使用してスキーマ変更データベースを同期する方法は？

于 2012-11-07T04:55:41.860 に答える
4

SyncFrameworkを使用したソリューションを使用します。

Microsoftからの引用：

Microsoft Sync Frameworkは、アプリケーション、サービス、およびデバイスのコラボレーションとオフラインを可能にする包括的な同期プラットフォームです。開発者は、任意のネットワーク上の任意のプロトコルを使用して、任意のアプリケーション、任意のストアからの任意のデータを統合する同期エコシステムを構築できます。Sync Frameworkは、ローミング、共有、およびデータのオフライン化を可能にするテクノロジーとツールを備えています。

Sync Frameworkの重要な側面は、カスタムプロバイダーを作成する機能です。プロバイダーは、任意のデータソースが同期フレームワーク同期プロセスに参加できるようにし、ピアツーピア同期を実行できるようにします。

于 2012-10-31T13:50:57.563 に答える
4

それは本当にあなたが使っているツールとあなたがすでに持っているアーキテクチャに依存します。ロジックとデータアクセス層を備えたサーバーはすでにありますか？

動的なアプローチは複雑で遅くなり、ソリューションの数が制限される可能性があります。なぜ動的構造が必要なのですか？リレーショナルデータベースで名前と値のペアのアプローチを使用してデータを追加することは可能でしょうか？静的で均一なデータ構造は、処理がはるかに簡単です。

詳細に入る前に、さまざまなシナリオを検討する必要があります。

  • アイテムを追加できます
  • アイテムは変更できます
  • アイテムは削除できます（私は推測します）

追加は大きな問題ではありません。クライアントはサーバーから取得した最後のリビジョン番号を覚えておく必要があり、そこからすべてを取得するクエリを作成します。

変更は基本的に同じです。アイテムの識別に注意する必要があります。すでにお持ちのIDのようですので、変更できない代理キーが必要です。（ここではGUIDが役立つ場合があります。）

削除には注意が必要です。アイテムを実際に削除するのではなく、削除済みとしてフラグを立てるか、削除されたIDのリストと削除されたときのリビジョン番号を用意する必要があります。

クライアントにデータを保存する：クライアントでSQLiteのようなリレーショナルデータベースを使用することを検討してください。（インストールする必要はありません。ファイルに保存するだけです。たとえば、FirefoxはSQLiteデータベースにかなりの量を保存します。）サーバーで同じものを使用する場合、おそらくいくつかのコードを再利用できます。また、トランザクションベースであるため、一貫性を保つことができます（同期中にエラーが発生した場合のロールバック）。

XML（本当に必要な場合）は、データベースに文字列として保存できます。

SQLiteをサポートする抽象化レイヤーまたはORM（NHibernateなど）を使用する場合、サーバーが使用する別のデータベースがある場合でも、一部のコードを再利用できます。このようなORMの学習曲線はかなり急な場合があることに注意してください。このようなことを知らなければ、多すぎるかもしれません。

クライアントとサーバーでコードを強制的に再利用する必要はありません。

同期自体はそれほど複雑であってはなりません。クライアントにはリビジョン番号があり、サーバーには最後のリビジョンがあります。それ以降、すべての新規/変更および削除されたアイテムをクライアントで取得し、ローカルストアに適用します。ローカルリビジョン番号を更新します。専念。終わり。

リビジョンの一部だけを更新することは決してありません。最後の同期以降に何が変更されたかを実際に知ることができないためです。差分更新を行うため、クライアントの状態を明確に定義することが不可欠です。

于 2012-11-06T07:38:42.243 に答える
2

バックエンドデータベースが何であるかはわかりませんが、SQL Serverの場合は、クライアントDBとしてSqlCE（SQL Server Compact Edition）を使用し、RDAマージレプリケーションを使用して、必要に応じてクライアントDBを更新できます。これにより、すべての要件が確実に処理されます。このような一般的な要件のために車輪を再発明する必要はありません。

于 2012-11-06T15:54:39.763 に答える