Asp.net mvc folder / object hierarchy

Question

Background

I have an Asp.net MVC 3.5 application that imports products using a CSV file. CSV files can come from a specific group of custom sources. To configure a new CSV source, the user will first determine which CSV columns are mapped to product properties. This configuration will be saved as an import template and after that it will be available for selection with each import.

I ran into a wall trying to plan the folder / object structure for this function. I understand (and love) the flexibility of Asp.net MVC for routing, so I know that we could do something here. Nevertheless, I would like to receive any advice that will help us to keep the structure of the object more reliable and supported.

First, I configure the Product folder containing the Import.aspx view. This seems to be good enough for the controller / action model. However, when I look at the template management functions mentioned above, everything becomes confusing.

EDIT: The import template can be applied to various objects. Thus, a product is just one object that can have one or more ImportTemplates for it. For example, another object that may have an ImportTemplate may be a Client.

Question

Should I create an ImportTemplate subfolder in the Product folder and place CRUD Views there? Then I will add a special route for Import Template functions. I am worried about the depth of the folders, as well as the confusion with the import of the actions of brothers and sisters. Or should ImportTemplate be level and then use routing to place it under the Product folder? Sounds random.

Perhaps the folder structure should be Product / Import / Template. The problem that I see in this case is that Import is not really an object. I see that this is a controller, but it is really intended for action. If I use this structure, should I place Upload.aspx View in the Import folder (to replace the Product / Import.aspx mentioned above)? It seems a little awkward.

EDIT: With the added requirement above that ImportTemplate could be associated with objects other than Product (e.g. Customer), would it be better to have the ImportTemplate folder directly below the Views folder?

Any alternative ideas for structuring this hierarchy of objects / folders?

Study

In an attempt to investigate this problem, I examined questions about folder structure and depth. Here are a few questions that were answered, but didn’t really answer my question.

- ASP.NET MVC How many levels should a view or URL have?

- ASP.NET MVC 3 folder structures

- Strategy hierarchical MVC routing

Example

EDIT: The user regularly imports a list of products from a third-party manufacturer. They import data from a CSV file that will be uploaded to the website. They create / add an instance of the product import template to their account. This template instance saves the following settings:

• The column with the name "title" in the CSV file must be imported into the "Product Name" field.
• Unrecognized categories in the category column in the CSV must be imported as the Unknown category.

Another user may have different rules based on another third-party CSV format or based on their own system configuration (i.e. they do not have the Unknown category setting as the user above).

• A column named "part number" in the CSV must be imported into the "Product Name" field and the "Product Number" field.
• Unrecognized categories should import by default into the General category.

Answer 1

You are absolutely right that, given the flexibility of ASP MVC, you can do something here regarding folder structure. If you used ASP.NET WebForms, remember that MVC is completely different in that it does not use folders and files as a direct resource mapping, and the routes are based on controllers and actions. It can get used to when you are used to doing it "ASP classic."

So, the main consideration is what matters the most to you and your users, and that everything is clear, where everything is.

Perhaps the folder structure should be Product / Import / Template. the problem that I see in this case is that Import is not really an object. I see that this is a controller, but it really should be an action. If I use this structure, should I place Upload.aspx View in the Import folder (to replace the mentioned Product / Import.aspx above)? It seems a little awkward.

Yes, it looks like your controllers should have an “Import” action, “Send action”, etc. .... Each of them may have a corresponding view in this folder for viewing controllers, but the templates themselves probably don't must be representations. Your templates are just a resource that the action of the controller will refer to when importing products. In this case, normal routing would not be a problem, and I would not place the templates as folders. The identifier places them in a central place and refers to them in all my controllers, which need to get access to them for the import action.

You can use something like this:

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

Import.aspx or Upload.aspx can be pages on which the user can select a template and import products (or display columns and save a new template). Each view will have a corresponding controller action. Your actions to import or load your controllers will directly access template files; all you have to do is enable the link to the ImportTemplate folder in your controller (or Model, Service Layer ... anywhere the template will be used)

 using MyApp.ImportTemplate //namespace matches folder structure, "MyApp/ImportTemplate" 

When the user is on the product import page, the URL will look like /Product/Import/ , and the template itself will not necessarily appear in the URL unless you pass it as the /Product/Import/templateID or /Product/Import?templateID=123456 parameter /Product/Import?templateID=123456 .

Again, the key is to do what works best for your projects, and allows you to organize and clean things up in such a way that you can save time when you create / deploy your application.

For example, I try to divide things into two or more projects to make it easier for me when the time comes for deployment. As an example, I might have a folder structure like this:

 App.UI project Content CSS Scripts Images Views App.Core project (any code that will be compiled) Controllers Templates Models Helpers Interfaces Repositories ViewModels 

Then all I need to deploy is the App.UI project, and everything in App.Core will be compiled and included in the App.UI\bin