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

Posted 2023-02-23

【中文标题】asp.net mvc 文件夹/对象层次结构

【英文标题】：asp.net mvc folder/object hierarchy

【发布时间】：2013-01-27 10:03:57

【问题描述】：

背景

我有一个使用 CSV 文件导入产品的 Asp.net MVC 3.5 应用程序。 CSV 文件可以来自一组特定的可配置源。要配置新的 CSV 源，用户最初会指定哪些 CSV 列映射到哪些产品属性。此配置将存储为导入模板，之后每次导入时可供选择。

我在尝试为此功能规划文件夹/对象结构时遇到了困难。我理解（并且喜欢）Asp.net MVC 在路由方面的灵活性，所以我知道我们可以在这里做任何事情。不过，我想要任何可以帮助我们保持对象结构更健全和更易于维护的建议。

最初我设置了一个包含 Import.aspx 视图的产品文件夹。这似乎很适合控制器/动作模型。但是，当我考虑管理上述模板的功能时，事情就变得混乱了。

编辑：导入模板可以应用于不同的对象。所以 Product 只是一个可以为其创建一个或多个 ImportTemplate 的对象。例如，可能具有 ImportTemplate 的另一个对象可能是 Customer。

问题

我应该在 Product 文件夹下创建一个名为 ImportTemplate 的子文件夹并将 CRUD 视图放在那里吗？然后我会为导入模板函数添加一个自定义路由。我在这里关心的是文件夹深度以及与兄弟操作导入的混淆。还是应该将 ImportTemplate 提升一个级别，然后使用路由将其放置在 Product 文件夹下？听起来很乱。

也许文件夹结构应该是产品/导入/模板。我在这种情况下看到的问题是 Import 并不是一个真正的对象。我可以看到它是一个控制器，但它实际上是 action。如果我使用这种结构，我是否应该在 Import 文件夹中放置一个 Upload.aspx 视图（以替换上面提到的 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

一个例子

编辑：用户定期从第三方导入产品列表。他们正在从将上传到网站的 CSV 文件中导入数据。他们创建/添加产品导入模板的实例到他们的帐户。此模板实例存储以下设置：

应将 CSV 文件中名为“title”的列导入“产品名称”字段。 CSV 中“类别”列下无法识别的类别应导入为“未知”类别。

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

CSV 中名为“部件号”的列应导入到产品名称字段和产品编号字段。 默认情况下，无法识别的类别应导入“通用”类别。

【问题讨论】：

您的模板是保存为视图还是仅仅是功能/保存的列映射？

@Jack 他们目前计划保存列的映射。

【参考方案1】：

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

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

也许文件夹结构应该是产品/导入/模板。这 我在这种情况下看到的问题是 Import 并不是一个真正的对象。 我可以看到它是一个控制器，但它实际上是 行动。如果我使用这种结构，我是否应该在其中放置一个 Upload.aspx 视图 Import 文件夹（替换提到的 Product/Import.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 传递。

同样，关键是做对您的项目最有意义的事情，让事情井井有条，让您清晰，并在构建/部署应用程序时节省您的时间。

例如，我倾向于将项目拆分为两个或多个项目，以便在部署时更轻松。例如，我可能有这样的文件夹结构：

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

【讨论】：

模板数量因用户选择导入的供应商而异。由于存在新供应商的可能性，并且由于他们为每个用户集成的方式也可能不同，因此 UI 将需要一些动态方法来添加、编辑和删除模板。添加和编辑模板“实例”不是一个或多个视图的好候选吗？我知道我可以让动态类在核心库中工作，但在这种情况下，每个模板的功能都是相同的。每个实例只会更改字段映射。