6

バックグラウンド

CSV ファイルを使用して製品をインポートする Asp.net MVC 3.5 アプリケーションがあります。CSV ファイルは、構成可能なソースの特定のグループから取得できます。新しい CSV ソースを構成するには、ユーザーは最初に、どの CSV 列がどの製品プロパティにマップされるかを指定します。この構成はインポート テンプレートとして保存され、その後、各インポートが実行されるときに選択できるようになります。

この機能のフォルダー/オブジェクト構造を計画しようとして、壁にぶつかりました。私は、ルーティングのための Asp.net MVC の柔軟性を理解しています (そして気に入っています)。ただし、オブジェクト構造をより健全で保守しやすいものに保つために役立つアドバイスがあればお願いします。

最初に、Import.aspx ビューを含む製品フォルダーをセットアップします。これは、コントローラー/アクション モデルに十分に適合しているようです。ただし、上記のテンプレートを管理するための機能を考えると、混乱が生じます。

編集: インポート テンプレートは、さまざまなオブジェクトに適用できます。したがって、Product は、1 つ以上の ImportTemplates を作成できるオブジェクトの 1 つにすぎません。たとえば、ImportTemplate を持つ可能性のある別のオブジェクトは、Customer である可能性があります。

質問

Product フォルダーの下に ImportTemplate というサブフォルダーを作成し、そこに CRUD ビューを配置する必要がありますか? 次に、Import Template 関数のカスタム ルートを追加します。ここでの私の懸念は、フォルダーの深さと、兄弟アクションのインポートとの混乱です。または、ImportTemplate を 1 レベル上げてから、ルーティングを使用して Product フォルダーの下に配置する必要がありますか? 乱雑に聞こえます。

おそらく、フォルダー構造は Product/Import/Template である必要があります。この場合の問題は、インポートが実際にはオブジェクトではないことです。コントローラーであることがわかりますが、実際にはアクションであることを意図しています。この構造を使用する場合、(上記の Product/Import.aspx を置き換えるために) Import フォルダーに Upload.aspx ビューを配置する必要がありますか? これはちょっとマシになりそうです。

編集: ImportTemplate を製品以外のオブジェクト (つまり、顧客) に関連付けることができるという上記の追加要件により、Views フォルダーの直下に ImportTemplate フォルダーを配置する方がよいでしょうか?

このオブジェクト/フォルダー階層を構築するための代替案はありますか?

リサーチ

この問題を調査するために、フォルダーの構造と深さに関する質問を確認しました。ここにいくつかの質問がありますが、実際には私の質問に対する答えはありませんでした。

- ASP.NET MVC ビューまたは URL は何レベルの深さにする必要がありますか?

- ASP.NET MVC 3 フォルダー構造

-階層型 MVC ルーティングの戦略

例

編集: ユーザーは定期的にサード パーティから製品のリストをインポートします。Web サイトにアップロードされる CSV ファイルからデータをインポートしています。製品インポート テンプレートのインスタンスをアカウントに作成/追加します。このテンプレート インスタンスには、次の設定が格納されます。

  • CSV ファイルの「タイトル」という名前の列は、製品名フィールドにインポートする必要があります。
  • CSV の「カテゴリ」列にある認識されないカテゴリは、「不明」カテゴリとしてインポートする必要があります。

別のユーザーは、別のサード パーティの CSV 形式に基づいて、または独自のシステム構成に基づいて、異なるルールを持つ場合があります (つまり、上記のユーザーのように不明なカテゴリが設定されていません)。

  • CSV の「部品番号」という名前の列は、製品名フィールドと製品番号フィールドにインポートする必要があります。
  • 認識されないカテゴリは、デフォルトで「汎用」カテゴリにインポートする必要があります。
4

1 に答える 1

0

ASP MVC の柔軟性を考えると、フォルダー構造に関してここでほぼ何でもできることは間違いありません。ASP.NET WebForms に慣れている場合、MVC はリソースの直接マッピングとしてフォルダーとファイルを使用せず、ルートはコントローラーとアクションに基づいているという点で完全に異なることに注意してください。これは、「ASP の従来の」方法に慣れている場合、慣れるまでに時間がかかる場合があります。

そのため、重要な考慮事項は、あなたとユーザーにとって何が最も理にかなっているのか、そして誰もがどこに何があるかを明確にすることです。

おそらく、フォルダー構造は Product/Import/Template である必要があります。この場合の問題は、インポートが実際にはオブジェクトではないことです。コントローラーであることがわかりますが、実際にはアクションを意図しています。この構造を使用する場合、(上記の Product/Import.aspx を置き換えるために) Import フォルダーに Upload.aspx ビューを配置する必要がありますか? これはちょっとマシになりそうです。

はい、コントローラーには Import アクションや Upload アクションなどが必要なようです…これらのそれぞれは、そのコントローラーのビューフォルダーに対応するビューを持つことができますが、テンプレート自体はおそらくビューである必要はありません。テンプレートは、製品をインポートするときにコントローラ アクションによって参照される単なるリソースです。この場合、カスタム ルーティングは問題にならないので、テンプレートをビュー フォルダーに配置しません。それらを中央の場所に置き、インポート アクションのためにそれらにアクセスする必要があるすべてのコントローラーでそれらを参照します。

次のようなものを使用できます。

MyApp project
    Controllers
        ProductController
    Models
        Product
    ImportTemplate
        Template1
        Template2
    Views
        Product
            Import.aspx
            Edit.aspx
            Index.aspx
            etc…

Import.aspxまたははUpload.aspx、ユーザーがテンプレートを選択して製品をインポートする (または列をマップして新しいテンプレートを保存する) ことができるページである可能性があります。各ビューには、対応するコントローラー アクションがあります。コントローラーのインポートまたはアップロード アクションは、テンプレート ファイルに直接アクセスします。必要なのは、コントローラー (またはモデル、サービス層など、テンプレートが使用される場所) に ImportTemplate フォルダーへの参照を含めることだけです。

using  MyApp.ImportTemplate
//namespace matches folder structure, “MyApp/ImportTemplate”

ユーザーが製品のインポート ページにいる場合、URL は似たものになり、パラメーターまたは/Product/Import/として渡さない限り、テンプレート自体が URL に表示されるとは限りません。/Product/Import/templateID/Product/Import?templateID=123456

繰り返しになりますが、重要なのは、プロジェクトにとって最も理にかなったことを行い、物事を整理して明確にし、アプリケーションを構築/デプロイするときに時間を節約できるようにすることです。

たとえば、私は物事を 2 つ以上のプロジェクトに分割して、展開するときが簡単になるようにする傾向があります。例として、次のようなフォルダー構造があるとします。

App.UI project
    Content
        CSS
    Scripts
    Images
    Views

App.Core project (any code that will be compiled)
    Controllers
    Templates
    Models
        Helpers
        Interfaces
        Repositories
    ViewModels

次に、展開する必要があるのはApp.UIプロジェクトだけです。すべてApp.Coreがコンパイルされ、App.UI\binフォルダーに含まれます

于 2013-02-21T18:18:53.647 に答える