ASP.Net MVC アプリケーションで Web サービスをモデルとして使用するためのアドバイスやヒントはありますか? これについて書いている人を見たことがありません。MVC アプリを構築したいのですが、それを特定のデータベースの使用に関連付けたり、データベースを単一の MVC アプリに限定したりしません。私は Web サービス (RESTful、おそらく ADO.Net Data Services) が進むべき道だと感じています。
5460 次
4 に答える
28
MVC アプリがデータベースから分離される可能性、または有用性はどの程度ですか? アプリケーションの寿命の中で、SQL Server から Oracle への変更はどのくらいの頻度で見られましたか? 私が提供してきた過去 10 年間のプロジェクトから、そのようなことは一度もありませんでした。
アーキテクチャはタマネギのようなもので、依存するものの上に抽象化されたレイヤーがあります。また、ストレージに RDBMS を使用する場合は、それがアーキテクチャの中核になります。DB から自分自身を抽象化して交換できるようにすることは、非常に誤りです。
これで、データベース アクセスをドメインから切り離すことができます。リポジトリ パターンは、その方法の 1 つです。最近の成熟したソリューションのほとんどは ORM を使用しているため、成熟したテクノロジーが必要な場合は NHibernate を調べてください。データに加えてよりシンプルなアクティブ レコード パターンを求める場合は ActiveRecord / linq2sql を検討してください。
データ戦略が整ったので、ある種のドメインができました。クライアントにデータを公開するときは、通常はドメインから生成された DTO をレンダリングのために送信する MVC パターンを使用するか、REST などのアーキテクチャ スタイルを利用して、より疎結合のシステムを提供するかを選択できます。 、リンクとカスタム表現を提供することにより。
ソリューションの外部レイヤーに進むにつれて、密結合から疎結合に移行します。
ただし、REST アーキテクチャまたは Web サービスの上に MVC アプリを構築し、それをモデルとして使用するという質問があった場合は...なぜわざわざ? ドメイン モデルを使用する場合は、システムやサービスで適切な場所でそれを再利用してみませんか?
MVC アプリから UI を生成することと、RESTful アーキテクチャに必要なドキュメントを生成することは、2 つの完全に異なるコンテキストです。互いの上に 1 つを基にすることは、必要以上の苦痛を引き起こすだけです。そして、パフォーマンスを犠牲にしています。
正確なシナリオによって異なりますが、MVC のモデルとしてのリモート XML ベースのサービスは、経験上、お勧めできません。おそらく、過度に設計されており、ドメインを開始する必要性を無視しています。
于 2009-06-03T02:03:49.087 に答える
3
リポジトリ パターンを使用するなど、データ アクセスに依存しない方法でモデルを定義する必要があります。次に、特定のデータ アクセス テクノロジ (Web サービス、SQL など) に基づく具体的な実装を作成できます。
于 2009-06-01T20:46:00.770 に答える
3
2010 年 11 月 27 日を編集。本当に必要だった私の考えを明確にしました。
Web サービスは、ほとんどの場合、1 つのアプリケーションで抽象化するためではなく、さまざまなタイプのアプリケーションにわたって機能を公開します。おそらく、コントローラー/ビューのプログラミングに干渉しない方法でコマンドと読み取りをカプセル化する方法を考えているでしょう。
分離後、非同期ページで非同期パターンを実行する場合は、サービス バスのサービスを使用します。Rhino.ServiceBus、nServiceBus、MassTransit は .Net ネイティブ実装で、RabbitMQは別のものhttp://blogs.digitar.com/jjww/2009/01/rabbits-and-warrens/で確認できます。
編集：メッセージをサービスにプッシュし、それが更新を簿記アプリにプッシュする方法でウサギを試す時間がありました。RabbitMQ はメッセージ ブローカー、別名 MOM (メッセージ指向ミドルウェア) であり、アプリケーション サーバーにメッセージを送信するために使用できます。
また、単純にサービス インターフェイスを提供することもできます。詳細については、Eric Evan の Domain Driven Design を参照してください。
REST-ful サービス インターフェイスは、データを大量に処理しますが、より具体的には、アドレス指定可能なリソースを処理します。プログラミング モデルを大幅に簡素化し、HTTP プロトコルを介して出力を細かく制御できます。WCF の今後のプログラミング モデルでは、元の論文で定義されているように真のレストを使用します。各ドキュメントは、ナビゲーションを継続するための URI をある程度提供する必要があります。これを見てください。(この投稿の最初のバージョンでは、REST が「遅い」ことを嘆きました。それが何を意味するにせよ) REST ベースの API は、CouchDBとRiakが使用するものとほとんど同じです。
ADO.Netはかなりがらくたです（！）[コードから実装への実装、データアクセスの漏れによる遅延コレクションのN + 1の問題-クエリコードなどのdbコンテキストが常に必要です]などと比較してLightSpeed（コマーシャル) または NHibernate。Spring.Net では、Web サービス ファサードを使用してサービス インターフェイスをコンテナー内にラップすることもできますが、(しばらくブラウズしないと) その構成が少し xmly すぎると思います。
編集 1: ここで ADO.Net を使用すると、DataSets、DataAdapter、および DataReader から多数の行を反復処理するデフォルトの「ベスト プラクティス」を意味します。それはかなり醜く、デバッグが難しいコードを生み出します。N+1 の話、はい、それはエンティティ フレームワークに関するものです。
(編集 2: EntityFramework も印象に残りません!)
編集 1: 別のアセンブリでドメイン レイヤーを作成します [aka. Core] を開き、そこですべてのドメイン サービスとアプリケーション サービスを提供してから、このアセンブリを特定の MVC アプリケーションからインポートします。データ アセンブリが参照および実装するコア アセンブリのインターフェイスを介して、一部の DAO/リポジトリにデータ アクセスをラップします。インターフェイスと実装を IoC と結び付けます。インターフェイスを解決するために、上記のサービス バスを使用して動的なサービス ディスカバリをプログラムすることもできます。WCF はこのようなインターフェイスを使用し、上記のほとんどのサービス バスも同様です。これを自動的に行うために、IoC コンテナに subcomponentresolver を提供できます。
編集 2: 上記の優れた組み合わせは、CQRS + EventSourcing + ReactiveExtensions です。書き込みモデルはコマンドを受け取り、ドメイン モデルはそれらを受け入れるかどうかを決定し、イベントをリアクティブ拡張パイプラインにプッシュします。おそらく、読み取りモデルが消費する RabbitMQ も使用します。
更新 2010-01-02 (編集 1)
私のアイデアの冗談は、MindTouch Dream と呼ばれるものによって成文化されました。彼らは、Web アプリケーションのほぼすべての部分を (Web) サービスとして扱うスクリーンキャストを作成しました。これも REST で公開されています。
彼らは、独自のエラスティック スレッド プールを含む、コルーチンを使用してこれを処理する高度な並列フレームワークを作成しました。
この質問のすべての否定論者に、あなたの顔で:p! 特に 12 分のこのスクリーン キャストを聞いてください。
この種のプログラミングに興味がある場合は、モナドの仕組みとC# での実装をご覧ください。CoRoutinesについても読むことができます。
明けましておめでとう！
2010-11-27 更新 (編集 2)
CoRoutines は Microsoft のタスク並列ライブラリで製品化されたことが判明しました。タスクは、IAsyncResult を実装するため、同じ機能を実装するようになりました。Caliburn は、それらを使用するクールなフレームワークです。
Reactive Extensions は、モナド内包表記を次のレベルの非同期性に引き上げました。
ALT.Net の世界は、私がほとんど知らなかった新しいタイプのアーキテクチャではありますが、この回答を初めて書いたときに私が話した方向に動いているようです。
于 2009-06-01T20:34:09.763 に答える
0
それは本当にこのMVCプロジェクトのサイズに依存します。少数のユーザー（<5000）がWebサイトを使用する場合は、UIとドメインを同じ実行環境に維持すると思います。
一方、何百万人ものユーザーがアクセスするサイトを計画している場合は、分散していると考える必要があります。つまり、スケールアップ/スケールアウトできる方法でWebサイトを構築する必要があります。つまり、追加のサーバー（Web、アプリケーション、およびデータベース）を使用する必要がある場合があります。
これがうまく機能するには、MVCUIサイトをアプリケーションから切り離す必要があります。アプリケーション層には通常、ドメインモデルが含まれ、WCFまたはサービスバスを介して公開される場合があります。サービスバスの方が信頼性が高く、msmqのような永続的なキューを使用する可能性があるため、私はサービスバスを好みます。
これがお役に立てば幸いです
于 2011-11-30T09:18:13.280 に答える