4

ASP.NET MVC を使用して非常に大きなアプリケーションを開発していますが、最初は、一般的な CRUD アクション (新規、保存、削除...) と既定のリスト アクションを備えた抽象ベース コントローラーを使用すると便利であることがわかりました。私たちの場合、この種のコントローラーを介して管理される 20 以上のエンティティがあります。

これは機能し、一部のコードの重複を回避し、アプリケーションをより均一にしますが、コントローラーが実装されているアクションを正確に確認するのが難しく、存在しないはずのアクションを実装する場合があります。たとえば、id ではなく名前を渡して編集したい場合、新しい EditByName(name) を作成する必要があり、それを行っても、ベースにあるので Edit(id) アクションを使用できます。

私には全体が少し臭いがしますが、私が目にする MVC アプリケーションのドメインはかなり狭いため、代替を示す例は見つかりませんでした。何かアドバイスはありますか？例はありますか？(私は必ずしも ASP.NET MVC にいるとは限りません。この問題は、どの MVC フレームワークにも共通していると思います)。

4

5 に答える 5

3

いくつかの点ではこれは良い考えだと思いますが、他の点では継承の悪用だと思います。私は共通の基本コントローラーを持っていますが、先験的に設計されたのではなく、コントローラーから共通コードをリファクタリングしたために存在します。エンティティが十分に似ていて、ベース コントローラーで共有しているコードが、引きずり回さなければならない粗雑さよりも重要である場合は、おそらくそれだけの価値があります。一方、共有されているコードがかなり最小限であり、作業を行うプライベート抽象メソッドを呼び出すだけの場合 (とにかく実際のコントローラーで実装しているため)、それが何を買うのかわかりません。 . あなたらしくない」

私の投票は、本当に一般的なものや分野横断的な懸念事項を基本クラスにリファクタリングし、実際には存在しない可能性のある「is-a」関係を強制しようとしないことです。

于 2009-07-14T12:00:34.693 に答える
1

私には全体が少しにおいがします。

ここで同じ匂い:-)

コントローラにコードをほとんど含まないのが一般的な方法です。その主な目的は、次にどのモデルでどのビューをレンダリングするかを決定することです。

表示されるすべてのコントローラーコードに共通の場所を設定したい場合は、コントローラーに多くのロジックが必要になる可能性があります。

logikをモデルに移動してみてください。フィルタとCustomModelBinderを使用します。

于 2009-07-14T13:48:23.503 に答える
1

これは、Rails が (関連する CRUD ビューを生成すると共に) パックするものの 1 つであり、非常に迅速なアプリケーションを作成するのに最適ですが、開発に真剣に取り組むようになると、通常の CRUD が残ることは非常にまれです。各テーブルに必要なものが変化し始め、さらにカスタマイズする必要があります。

開発やプロトタイピングの際に便利な基盤や便利な設定方法を形成しないと言っているわけではありません - データベース分野でいじくり回すよりもはるかに簡単ですが、Rails での操作方法は確かにありません。これらのページのいずれかが最終的な管理システムにあるとは思わないでください。

于 2009-07-14T11:57:15.680 に答える
0

念のため: ご存知のように、ASP.NET MVC は Ruby on Rails のような基本的な足場をサポートしています。特定のニーズを満たすために、作成、更新、詳細ビューの作成に使用される T4 ファイルをカスタマイズすることを検討してください。

http://blogs.msdn.com/webdevtools/archive/2009/01/29/t4-templates-a-quick-start-guide-for-asp-net-mvc-developers.aspx

于 2009-07-14T17:15:12.253 に答える