リモートまたはリモートではない？

Question

リモートまたはリモートにしないには？

私の用語が100％正しくない場合は、私を許してください。

中小企業向けに長年にわたりソフトウェア（すべてのWindowsフォームアプリケーション）を開発した後、私は最近、私の岩の下から這い出し、Remotingおよび/またはWCFの概念を発見しました。私が過去に取り組んできたすべてのプロジェクトでは、クライアントマシンのそれぞれがデータベースサーバーに直接接続していました。 「Microsoft .Net：エンタープライズ向けアプリケーションの設計」を読んだところ、WCFを介してビジネスオブジェクトをPOCOオブジェクトとして公開する方が、クライアントアプリケーションにデータベースクライアントソフトウェアをインストールする必要がないそれぞれのマシン（マシンごとに別のdbユーザーライセンスのようなもの）があります。クライアントアプリケーションは、WCFサービスに接続するだけで、ビジネスオブジェクトのラッパーとして「サービスレイヤー」を公開する必要があります。

私は狂ったのですか、これは分散アプリケーションの一般的なアプローチですか？

さらに、ORMソリューションをデータベースで指し、DALとビジネスオブジェクトを作成してWCF経由で公開することができますか？

私もかなり、私は他の人のためのORMの質問を残すつもりです...このシナリオでどのように動作するかを遅延ロードを中心に

おかげで、 ジョナサン

Answer 1

を私の心をラップすることができず、これが一般的なアプローチであるかどうかを質問する部分にのみ回答してください。

これはSOA（Service-Oriented Architecture）と呼ばれる一般的なアプローチです。それには多くの利点があり、落とし穴もあります。それは数年前にすべての話題でしたが、今でも一般的に使用されていますが、興奮のレベルは下がりました。

まだ、Webにはこれを研究するための膨大なリソースがあります。最大のキャッチは、SOAがどのように実装されるべきか、そしてそれが何を意味するのかについて、異なる人々が異なる考えを持っているため、先に考えることです。また、クロスプラットフォームの約束は、当初期待していたよりも実際には達成するのが難しいです。 （例えば、Javaから.NET Webサービスを呼び出すことはできますが、これを実行することはできますが、それを動作させるためには両方の作業を行う必要があります）。したがって、プラットフォーム間の互換性について心配する必要がある場合は、あまりにも深くなる前に、「クロスプラットフォームの互換性」が必要です。後でパンツを掴んで、もともとはJavaクライアントが必要な.NETクライアント向けの一連のサービスを再作成する必要がないように、その方法を学ぶ方が良い（スマートフォンアプリの場合など）。

私たちはこの間違いを犯し、Android/Blackberryクライアントが消費する必要のあるサービスを開発し始めたときに、大量のWebサービスを再作成する必要がありました。業界がスマートフォンの開発に向かう途上であることを考えると、今すぐ取得することで、後で多くの作業を省くことができます。

Answer 2

SOAが停止しています。 MOA（Message-Oriented Architecture）を使用した標準の.Net Remotingが道です！