ASP.NET MVC文件夹/对象层次结构

Question

ASP.NET MVC文件夹/对象层次结构

asp.net-mvcooparchitectureimportimport-from-csv

6

背景

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

在试图规划此功能的文件夹/对象结构时，我遇到了困难。我了解（并喜欢）Asp.net MVC的灵活性，所以我知道我们几乎可以做任何事情。但是，我希望获得任何有助于保持对象结构更加完整和可维护的建议。

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

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

问题

我应该在Product文件夹下创建名为ImportTemplate的子文件夹，并在其中放置CRUD视图吗？然后我会添加自定义路由以进行Import Template功能。我担心的是文件夹深度以及与同级操作Import的混淆。或者，ImportTemplate是否应该在上一级然后使用路由将其放置在Product文件夹下？听起来有点混乱。

也许文件夹结构应该是Product/Import/Template。我在这种情况下看到的问题是，导入并不是实际的对象。我可以看到它是一个控制器，但它确实意味着操作。如果我使用此结构，那么我应该将Upload.aspx视图放在Import文件夹中（以替换上述的Product/Import.aspx）吗？这似乎有点笨重。

编辑：由于上述要求增加了ImportTemplate可以与除Product之外的其他对象相关联（例如Customer），因此直接将ImportTemplate文件夹放在Views文件夹下是否更好？

有关组织此对象/文件夹层次结构的任何备选想法吗？

研究

为了研究这个问题，我回顾了关于文件夹结构和深度的问题。以下是几个问题，它们都有答案，但并没有提供我的问题的答案。

-ASP.NET MVC视图或URL应该有多少级别？

-Asp.net MVC 3文件夹结构

-层次MVC路由策略

一个例子

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

CSV文件中名为“title”的列应导入到产品名称字段。
在CSV的“category”列下未识别的类别应作为“Unknown”类别导入。

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

CSV文件中名为“part number”的列应导入到产品名称字段和产品编号字段。
未识别的类别应默认导入到“Generic”类别中。

- Rich C

你的模板是保存为视图还是仅仅是函数/保存列映射？ - Jack

@Jack，它们目前计划保存为列的映射。 - Rich C

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Jack · Answer 1

您说得非常正确，由于 ASP MVC 的灵活性，您可以在文件夹结构方面做任何事情。如果您习惯于 ASP.NET WebForms，请记住 MVC 完全不同，因为它不使用文件夹和文件作为资源的直接映射，而路由是基于控制器和操作的。当您习惯于以“ASP经典”方式进行操作时，这可能需要一些时间来适应。

因此，关键考虑因素是什么对您和您的用户最有意义，并且每个人都清楚所有内容的位置。

也许文件夹结构应该是 Product/Import/Template。在这种情况下，我看到的问题是 Import 实际上并不是一个对象。我可以将其视为控制器，但它确实是要执行的操作。如果我使用此结构，是否应在 Import 文件夹中放置 Upload.aspx 视图（以替换上述提到的 Product/Import.aspx）？这似乎有点笨拙。

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

你可以使用类似这样的东西：

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