4

夜間と週末にマイクロ ISV をブートストラップしようとしています。開発の非常に初期段階にあるアプリケーションがあります。これは C# で書かれており、主に問題領域を表すクラスのコレクションで構成されています。この時点では、UI またはデータの永続性はありません。(私はまだ .NET プラットフォームに落ち着いていません。Java やネイティブの実行可能ファイルに変更できるほど初期の段階です)

このアプリケーションの私の目標は、ハイブリッドのシングル ユーザー/時々接続されるマルチユーザー アプリケーションになることです。シングル ユーザー パーツは、ローカル ストレージに組み込みデータベースを使用します。これは私がよく知っている開発モデルです。

マルチユーザーの部分は、私が以前に経験したことがないところです。各ユーザーには次の 2 つのものが必要です。

  • パブリック インターネット上のリモート サーバーへの IP ベースの通信

  • ユーザー認証とリモート データ ストレージ

このサーバーに提供してもらいたいサービス (情報の検索とユーザー間のトランザクション) についての考えはありますが、それ以上は私の要素から外れています。自分のサーバーを実行するリソースがないため、サーバーはサードパーティによってホストされる必要があります。近い将来、私がこのプロジェクトの唯一の開発者になることを心に留めておいてください。

  1. 上記の 2 つのことを実装する最も簡単な方法は、どのテクノロジですか? データストア/データベースへの直接アクセスですか、それとも分離した方がよいですか? Web サービスを実装する必要がありますか? もしそうなら、SOAPかRESTか?

  2. マルチユーザー アプリケーションに移行する場合、他にどのようなことを考慮する必要がありますか? マルチユーザー アプリケーションでは、セキュリティがより大きな関心事であることを私は知っています。特に、あらゆる種類の銀行情報を扱う場合(私はそうします)。リモート接続や多数のユーザーを扱う場合、パフォーマンスが問題になる可能性があります。他に見落としているものはありますか?

4

3 に答える 3

2

マルチユーザー アプリケーションへの移行に関しては、もちろん、データを一元化することが最初のステップです。これを実現する最も簡単な方法は、多くの場合、Amazon SimpleDB や MS Azure などのクラウドベースのデータベースを使用することです。通常、認証用のアクセス キーと長い「シークレット」を取得します。

データのリレーショナル性が高くない場合は、Amazon SimpleDB を検討することをお勧めします。ほとんどの言語用の SDK があり、世界中のどこにいても、キーとシークレットを使用してシンプルなコードで SimpleDB データベースにデータを保存/取得できます。データストレージとトラフィック量に基づいてサービスの料金を支払うため、特に開発中の参入障壁は非常に低くなります. また、小さなホーム アプリケーションから amazon.com のサイズまで拡張できます。

独自のデータベース サーバーを実装することを選択した場合は、次の 2 つの重要なことを覚えておく必要があります。

  1. セッション状態が存在しないことを確認します。つまり、クライアントが Web サービスを呼び出し、何らかのアクションが発生し、サーバーはそのクライアントを忘れます (もちろん、データベース内の変更されたデータは別として)。同様に、クライアントは、別のユーザーからの対話の結果として変更される可能性のあるデータをローカルに保持するべきではありません。変更されないことがわかっている (または変更されてもかまわない) データのみをローカルにキャッシュします。
  2. Web サービスの場合、通常、各呼び出しは独自のスレッドで処理されるため、複数のスレッドからデータベースへのアクセスが安全であることを確認する必要があります。標準の .NET または Java の方法で SQL データベースとやり取りする場合は、これを処理する必要があります。ただし、独自のデータ ストレージを実装する場合は、心配する必要があります。

REST/SOAP などの問題に関しては、データベース サーバーへの接続に使用するプラットフォーム/デバイスの種類を考慮する必要があります。たとえば、.NET でサーバーを実装している場合、Web サービスの実装に WCF を検討できます。ただし、後で .NET 以外のクライアントを使用する場合は、問題が発生する可能性があります。SOAP は Web サービス向けの成熟したテクノロジですが、実装が非常に面倒であり、SOAP 呼び出しの処理をまとめるためのライブラリが特定のクライアント プラットフォームで利用できるとは限りません。REST は簡単に実装でき (サーバーで ASP.NET MVC を使用する場合は簡単です)、ライブラリを必要とせずに HTTP POST/GET を処理できる任意のクライアントからアクセスでき、テストも簡単です。したがって、REST は私の選択したテクノロジです。 .

于 2010-09-13T16:29:03.940 に答える
1

.net (私の個人的な好み) に固執している場合は、WCF を介してデータ アクセス呼び出しを公開します。WCF 構成は非常に柔軟で、非常に簡単に理解できるため、DB をサービス層の背後に隠したいと思うでしょう。

于 2010-09-13T16:28:31.213 に答える
0

1.dbへの直接アクセスは最も単純で、最悪です。dbアクセスを認証する方法を考えてみてください...シリアル化可能なパラメーターを使用してリモート対応のAPIを作成し、後で接続するメソッド(Webサービス、IIOPなど)について心配します-通信の詳細はすべてラップされていますとにかく隠されています。

2.なし

于 2010-09-13T16:23:26.453 に答える