asp.net-mvc - asp.net mvc 文件夹/对象层次结构

Question

背景
我有一个 Asp.net MVC 3.5 应用程序，它使用 CSV 文件导入产品。 CSV 文件可以来自一组特定的可配置源。要配置新的 CSV 源，用户最初应指定哪些 CSV 列映射到哪些产品属性。此配置将存储为导入模板，并在执行每次导入时可供选择。
我在尝试为此功能规划文件夹/对象结构时遇到了障碍。我理解(并喜欢)Asp.net MVC 路由的灵活性，所以我知道我们可以在这里做任何事情。但是，我想要任何可以帮助我们保持对象结构更健全和可维护的建议。
最初，我设置了一个包含 Import.aspx View 的 Product 文件夹。这似乎非常适合 Controller / Action 模型。然而，当我考虑管理上述模板的功能时，事情变得困惑。
编辑:导入模板可以应用于不同的对象。因此 Product 只是一个可以为其创建一个或多个 ImportTemplate 的对象。例如，另一个可能具有 ImportTemplate 的对象可能是 Customer。
题
我应该在 Product 文件夹下创建一个名为 ImportTemplate 的子文件夹并将 CRUD View 放在那里吗？然后我会为导入模板功能添加一个自定义路由。我在这里担心的是文件夹深度以及与同级操作导入的混淆。还是应该将 ImportTemplate 提升一个级别，然后使用路由将其放置在 Product 文件夹下？听起来很乱。
也许文件夹结构应该是产品/导入/模板。我在这种情况下看到的问题是 Import 并不是真正的对象。我可以看到它是一个 Controller ，但它实际上是一个 Action 。如果我使用这种结构，我是否应该在导入文件夹中放置一个 Upload.aspx View (以替换上面提到的 Product/Import.aspx)？这似乎变得有点笨拙。
编辑:根据上面添加的要求，ImportTemplate 可以与产品(即客户)以外的对象相关联，将 ImportTemplate 文件夹直接放在 Views 文件夹下会更好吗？
构建此对象/文件夹层次结构的任何替代想法？
研究
为了研究这个问题，我回顾了有关文件夹结构和深度的问题。这里有几个问题有答案，但确实没有为我的问题提供答案。
- ASP.NET MVC How many levels deep should a view or URL be?
- ASP.NET MVC 3 folder structures
- Strategy for Hierarchical MVC Routing
一个例子
编辑:用户定期从第 3 方导入产品列表。他们正在从将上传到网站的 CSV 文件中导入数据。他们创建/添加产品导入模板的实例到他们的帐户。此模板实例存储以下设置:

CSV 文件中名为“title”的列应导入到“产品名称”字段中。

CSV 中“类别”列下无法识别的类别应作为“未知”类别导入。

不同的用户可能基于不同的 3rd 方 CSV 格式或基于他们自己的系统配置有不同的规则(即，他们没有上述用户的未知类别设置)。

CSV 中名为“零件编号”的列应导入到产品名称字段和产品编号字段。

默认情况下，无法识别的类别应导入“通用”类别。

Answer 1

你完全正确，鉴于 ASP MVC 的灵活性，你可以在这里做任何关于文件夹结构的事情。如果您习惯了 ASP.NET WebForms，请记住 MVC 完全不同，它不使用文件夹和文件作为资源的直接映射，路由基于 Controller 和操作。当您习惯了“ASP 经典”方式时，这可能需要习惯。

因此，关键考虑的是什么对您和您的用户最有意义，并且每个人都清楚一切都在哪里。

Maybe the folder structure should be Product/Import/Template. The problem I see in this case is that the Import is not really an object. I can see it being a controller but it is really meant to be the action. If I use this structure, should I place an Upload.aspx View in the Import folder (to replace the Product/Import.aspx mentioned above)? This seems to get a little clunky.

是的，听起来你的 Controller 应该有一个导入 Action ，或上传 Action ，等等……这些 Action 中的每一个都可以在该 Controller 的 View 文件夹中有一个对应的 View ，但模板本身可能不需要是 View 。您的模板只是一种资源，在导入产品时将由 Controller 操作引用。在这种情况下，自定义路由不会成为问题，我不会将模板放在 View 文件夹中。我会将它们放在一个中央位置，并在我所有需要访问它们以进行导入操作的 Controller 中引用它们。

你可以使用这样的东西:

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

Import.aspx 或 Upload.aspx 可能是用户可以选择模板并导入产品(或映射列并保存新模板)的页面。每个 View 都有一个对应的 Controller Action 。您的 Controller 的导入或上传操作将直接访问模板文件；您需要做的就是在您的 Controller 中包含对 ImportTemplate 文件夹的引用(或模型、服务层……任何将使用模板的地方)

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

当用户在产品导入页面上时，URL 将类似于 /Product/Import/ 并且模板本身不一定出现在 URL 中，除非您将其作为参数 /Product/Import/templateID 或 /Product/Import?templateID=123456 传递。

同样，关键是做对你的项目最有意义的事情，让事情对你来说有条理和清晰，并且在构建/部署应用程序时可以节省你的时间。

例如，我倾向于将事情分成两个或更多项目，以便在部署时更容易。例如，我可能有这样的文件夹结构:

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文件夹中