Possible to use areas and features together? about addfeaturefolders

[OdeToCode]

Personally, I've only needed side-by-side to work when migrating an existing project to use feature folders. That is a good use case, so I'll look at making sure it works (I haven't tried it).

I don't see the use case for areas + feature folders, but it might just be a personal bias. Feature folders can be hierarchical, so I can have Features\Admin, Features\Books, and inside these folders have feature implementations, so Features\Admin\Users\ManageUsersController and Features\Admin\Settings\TenantSettingsController, etc. If you want to call your feature folder Areas, it would be almost the same (except no need for Controllers and Views to be in distinct separate folders).

[denisz1]

@OdeToCode I hope I understand:

• Features\Corporate\Billing
• Features\Corporate\Accounts
• Features\Corporate\Orders
• Features\Branch\Billing
• Features\Branch\Accounts
• Features\Branch\Orders

In theory only two features (Corporate and Branch).

They contain "sub-features" (Billing, Accounts, Orders) which work exactly like "super-feature".

But:

Will path resolution (explain in that article as {0}, {1}, {2}, {3}) finding these sub-features correctly? And to construct links with tag helpers (asp-action="" etc.) cannot be confused because of this hierarchy?

I will test some more to understand.

[kasparkallas]

One of the reasons to use Areas could be to enforce usage of given area base controller. If a controller in the area does not inherit the area base controller (which has the AreaAttribute) then its views won't be found by MVC.

[thiagomajesk]

There is a serious problem with the lack of "area-like" implementation in Feature Folders, or at least with the general structure. I'll give a simple example:

• Features\User\UserController
• Features\Admin\User\UserController

Both actions will be mapped to /user/{id} and throw an AmbiguousActionException.
I would expect the first one to be mapped acordingly to its structure: /admin/user/{id}.
Can someone fix this?

[OdeToCode]

Use route attributes like on your controllers like:

[Route("[controller]") for first controller.
[Route("admin/[controller]") for the second controller.

You'll have the same URL structure as you would have with areas, but without the ugliness of areas.

[thiagomajesk]

@OdeToCode This is just a awfull solution because when you specify an [Route] on your controller you'll have to manually override every single action to match the desirable template.
Another problem is that default routes like Index can only be access by its full path (controller/action/index) because there is not way to specify default values for routes using DataAttributes. Even using [Route("admin/[controller]/[action]")] seems not to be enough.

My proposal is to make subfolders being discovered by the default route configuration. That way, like I said before we could emulate the behavior of an area like I've shown before without the ungliness of areas (in the traditional way).

[OdeToCode]

Many times I'll create controllers with a single responsibility implemented in a single action. For example, the home page feature can have a controller with a Route("/") attribute and a single default action inside. Other read-only controllers that exist to present data are similar, just a single route attribute required. For complex object display scenarios where there are multiple actions inside, Route("movies/{movieId}/[action]") type routes work well enough and I don't need additional attributes inside the controller. Plus, the parameter names come out better in the system because developers don't get lazy and use the conventional "id" parameter everywhere. For controllers with postbacks you are usually adding the verb constraints in any case, and the verb attributes also allow you to add the parameters, if need be (HttpGet("{movieid?}").

The reason I mention all this is because I've come to dislike the conventional routing in ASP.NET MVC. It's not so much the convention as how the convention leads developers to create controllers with too many responsibilities (list things, detail a thing, create, update, and delete a thing), and every parameter is named "id".

I'm sure I might be missing your point, but I think we just want to take different approaches.

[kasparkallas]

@thiagomajesk I don't use MVC areas myself but I did get them to work. You just have to make small modifications to 2 files from this repository. Copy ServiceCollectionExtensions and FeatureControllerModelConvention. In ServiceCollectionExtensions.AddRazorOptions() add appropriate AreaViewLocationFormats any way you like. In FeatureControllerModelConvention.DeriveFeatureFolderName() you need replace .SkipWhile(s => s != _folderName) with something like the this .SkipWhile(s => s != _folderName || s != "Areas").

@OdeToCode A small advantage of MVC areas is that you can re-use controller names if I remember correctly.

[thiagomajesk]

@kasparkallas That seems to be a good workaround, but my main goal is to show the advantage of emulating this behavior by just extending the current path-convention. Instead of all controllers using relative paths to the root, would be better to have them check whether you are on the high level of feature-folders or a subfolder, and then map accordingly like this:

• /Features/Product/ProductController/Index -> /product
• /Features/Product/ProductController/Edit -> /product/edit
• /Features/User/UserController/Index -> /user
• /Features/Product/Admin/UserController/Index -> /product/user

Another alternative to this solution is check for the [Area] attribute when constructing the routes (Maybe thats easier, but still the default behavior should be the aforementioned).