The project I'm starting to work at will have several dozens of controllers, so it would be nice to structure them into logical directories and respective namespaces, like "Controllers/Admin/", "Controllers/Warehouse/Supplies/", etc.
Does ASP.NET MVC support nested controller directories and namespacing?
How do I manage routes to those controllers?
You can put the controllers anywhere; routes do not depend on where a controller is stored. It will be able to find any class that implements IController within your application.
I usually keep my controllers in a separate project, f.ex a MyProject.Frontend project, alongisde a MyProject.Frontend.Application project which is the actual entrypoint web project with the views etc.
Related
I am not to relate to Areas in MVC, why cannot we have simple folders to indicate modules, is the web.config which needs to be there, the below is the reason why i am asking this
Views -unfortunately for views it’s not possible. All the views must be placed inside “~/Views/ControllerName” or “~/Views/Shared” folder.
The following article describes in detail the reasons for Areas and the difference between Areas and folder-based conventions in ASP.NET MVC.
http://www.codeguru.com/csharp/.net/net_asp/mvc/article.php/c20227/Using-Areas-in-ASPNET-MVC-Application.htm
The essential idea is contained in the Introduction of the article:
ASP.NET MVC relies on certain folder and class naming conventions to
organize models, views and controllers. A large application often
consists of functionally independent modules with the result that the
main application is essentially a bundle of these sub-applications. In
such cases, organizing various models, views and controllers can be
tedious. Luckily, ASP.NET MVC allows you to split your application
into what is known as Areas. Each area mimics the folder structure and
conventions as required by ASP.NET MVC. This article shows you how
Areas are used in an ASP.NET MVC application.
When someone is trying to develop a sub-module suitable for inclusion in any ASP.NET MVC application (as an example, think deployment/inclusion of 3rd party code via a NUGET package) then the Areas construct is very helpful, and arguably a necessity.
Areas are folder structure which contains its independent set of Controller,
View, Model. Consider we are creating an area called Admin then the folder structure for the Admin area will be,
The same setup can be created by adding folders, Subfolder, and Required files.
Get ready for yet another elementary question from me...I think I have a grasp on the Area concept in a MVC site, but I would like to organize them even further, could I either move them to an external project (with controllers, views, scripts, styles) or create sub-folders within the Area folder?
Reason I'm asking is that I have tried to create a folder under Areas and called it Common, then created an area inside that folder and called it MyTest. When I attempt to browse to mysite.com/mytest, it fails.
You should try to go the usual way and use areas as a subfolder of the Areas ASP.NET root folder. The only reason why your URL would fail is that your AreaRegistration file is not properly registering your route. You can check out Glimpse as a way to debug routes or simply look at the files and try to figure it out your self. Keep in mind that ASP.NET automatically look for classes that inherit from AreaRegistration and use them to register routes that are specific to your area. If your routes seem to be configured properly, make sure your controllers are in namespaces that are visible to the route.
If you want to isolate the areas (with the controllers models and views) into separate projets, you should look into creating your own VirtualPathProvider, because that's the only way for your views to be located. However, they would have to be Embedded Resource and couldn't be debuuged. Your area, if located in a separate DLL, would be automatically registered and your controllers would be automatically found as long as the DLL is in the main application Bin folder.
I've watched a lot of video tutorials and read even more articles. I don't think I've seen one that answers this question and I'm stuck. :S
I created an MVC4 Application with Web API. Going off of the tutorials I've read I went with a standard naming convention. Say for example, /api/user and /api/user/id, etc.
Now I would like to create CRUD pages for the User entity. Of course, these pages would fit well under the /Admin/ folder, but I can't create a controller that generates views of /Admin/User/Create, /Admin/User/View, etc., since this would require creating a controller called UserController - but this is already created for the WebAPI.
Doesn't it seem standard or at least 'ok' to create CRUD pages for my Entities with this folder structure:
Views/Admin/User/
Views/Admin/Product/
etc, etc.
This allows each entity/table to have its own folder with its own Create.cshtml, Index.cshtml, etc.
But again, I have already created a WebAPI with this structure:
api/User/
api/Product/
So, now I want to create some Admin pages to manage the database. When I create a MVC controller with read/write using Entity Framework I can't figure out what to name the controller to give me the URI structure I'm wanting.
Of course, I don't really care what the controllers are called, but I don't know what steps are required to get the URI structure. For example, I created an MVC controller and named it AdminProduct, but now I have to go to /AdminProduct/ to see those pages.
Can someone point me?
You can have two controllers with the same name as long as they are in different namespaces. For example, I add all of my System.Web.Http.ApiController classes under the /Controllers/Api folder in my project. By default, Visual Studio will include these controllers in a namespace called <ProjectName>.Controllers.Api. Then, inside the /Controllers folder you can add System.Web.Mvc.Controller classes there, and they will be in the <ProjectName>.Controllers namespace. So, long-story-short, you can have an MVC controller named UserController and a WebApi controller named UserController, and there is no conflict.
The views for your MVC controller actions, like /User/Create and /User/Delete should be put under the /Views/User/ folder of your project - each with the same name as the action in the UserController. As far as having admin pages, why not create an AdminController or using the [Authorize] action filter on those actions you want secured?
I'm not sure I understood your entire problem. ASP.NET MVC binds controller names and actions to views by this convention.
I am working on asp.net mvc project which is quite large in size. I am new to the MVC stuff.
As Asp.Net MVC have default folder structure Controller, Views or Model so can we change this structure. what if instead of Controller i have different folder? Is it possible?
Although it is possible to change the LocationFormats of a view engine, this isn't recommended as it messes with the standard MVC conventions.
Instead, you should consider using Areas for each of your major 'modules' of functionality.
Your folder structure will then be similar to:
/(MVC Root)
/Areas
/Sales
/Controllers
/Views
/Financials
/Controllers
/Views
etc.
I have some action filters that I want to apply to more than one controller. I looked around but can see no MVC conventions on where to place these files. The only place I was able to see them used was in NerdDinner and in that case all I could find was an onactionexecuting method that was inside of a controller.
For those of you who use Action Filters. Where do you place these in the MVC file structure?
They go into a folder in the same level as the Models Views and Controller level, called ActionFilters.
I've also seen them go into a subfolder under Controllers, since they normally apply to actions on controllers.
I place all ActionFilter classes in a folder simply called Filters in the MVC project.
However, my team recently created a Web.Mvc.Common project, and that's where we put the Filters folder now, so that they can easily be reused by other projects.