9

注: これは、x が x よりも優れているという投稿にはほど遠いものです。そこに行かないでください。

私は .Net 派で、初期のバージョン 2 ベータ版とそれ以降のすべてのバージョンから MVC フレームワークを使用してきました。過去数か月間、私は Rails をいじっていましたが、2 つのプラットフォーム間で大きく異なるように見えるアーキテクチャについて質問があります。(コミュニティや SO などのサイトの質問に基づく)

.Net MVC では、懸念事項を分離し、データ アクセス、ビジネス ロジック、およびビューを処理するために個別のプロジェクトを作成することをお勧めします。また、データ オブジェクトをビューにヒットする前に ViewModel に変換する必要があるとも言われています。

Rails では、物事はかなり単純に見えます。Validation、DataAccess (アクティブ レコード経由)、およびその他の論理プロパティを含むオブジェクトがあり、それを View に送信して表示するだけです。

では、あるフレームワークではこの方法論が受け入れられるのに、別のフレームワークでは間違っているとみなされ、最終的にはより多くのコードを記述し、より多くのファイルを作成することになるのはなぜでしょうか。

注 : 私は Rails の専門家ではありません。どちらが x より優れているかを比較しようとしているわけではありません。

4

1 に答える 1

6

それは、開発しているアプリケーションの種類と、それがどれだけ成長すると予想されるかによって異なります。

単純なアプリケーションの場合、さまざまなビュー モデルとドメイン モデルを使用して物事を複雑にする必要はありません (ただし、別のビュー モデルとエンティティを使用することもできます: http://blog.gauffin.org/2011/07/three-reasons-to-why -you-should-use-view-models/ )。

CRUD アプリケーションの場合、リポジトリ パターンなどの抽象化でデータ アクセスをラップする必要はありません。

しかし、些細なアプリケーションや CRUD アプリケーション以外のコードを作成する予定がある場合は、そうすることをお勧めします。パターンと原則は、アプリケーションの保守を開始したい日に役立ちます。より小さく、より明確に定義されたクラスが得られ、ビジネス ロジックはアプリケーション全体ではなく 1 か所で作成されます。

抽象化を使用する理由について、小さなブログ エントリを書きました: http://blog.gauffin.org/2013/01/data-layer-the-right-way/

カプセル化が重要な理由: http://blog.gauffin.org/2012/06/protect-your-data/

于 2013-02-08T14:19:38.537 に答える