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.
Related
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.
In tutorials and walkthroughs on developing an MVC3 (MVC2) using EF (EntityFramework, Entity Framework 4.1/4.2) I observe quite different orders of adding Model, View, Controller to a project in a Microsoft Visual Studio 2010.
What are cons and pros of different orders of adding M, V and Cs?
and of, for example, adding a model before and, more specifically, after a view and controller?
There is no specific rules for adding one over the other first. When you create an empty ASP.NET MVC3 Project, It will come with some default folder structure which includes one Controller folder, Views folder and Models folder.
Now If you are beginner, This is what i suggest. Add a controller first.
Simply right click ont he Controller folder and Select Add->Controller from the context menu and add your first controller(Give the name as HomeController). It will come with a Default Index action method and you can see a return View statement. Run your project now. It will show you an error saying that it can not find a view. So now it is the time to add a view. Go the index action in home controller. Right click on the Return View() statement and select Add View that will add a view (index.xshtml) under the home folder under Views. Now run the app and you will see the page content.
If you are going to interact with your database, you can add model classes. If you can add POCO class file to your Models folder or you can have it on a different library which is refered to this projcet. It's all up to you.
As Lavinski mentioned, If you create your models first, You can use Scaffolding to create the controller actions for you. But If you are beginner, I would suggest you to create your controllers and views by hand. That will help you to understand MVC configuration works
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.
I'm trying to create a strongly typed view model as John Sheehan suggests here. Where should it go? I can make arguments to myself for Model, View, and Controller.
It should go in the "Models" directory of the web app. ViewModels are by definition specific to one or more views and therefore belong in the web app, not the core.
You could define them in the controller that uses them, but this doesn't scale. Same with defining the class in the view code. Even though one-class-per-file means more files, its easier to find code and easier to maintain.
I'll often create a subfolder for each controller, so I end up with things like Web.Models.Foo.BarViewModel.
If have them in my Domain project in a PresentationModel directory and like #Seth Pretry-Johnson, I have them in separate Controller directories.
This is my overall structure of a project:
Website Project
Controllers
Views
Etc
Domain Project
Models
Repositories
Abstract
Services
Abstract
PresentationModels
Home
User
Etc
DataAccess Project
Repositories
HTHs (and doesn't raise more questions.. ;-),
Charles
I put the actual model class in the Models folder.
/Controllers
/Models
/Entities
/Mappings
/ValueTypes
/ViewModels
Something like that. I'm a big fan of the Fluent NHibernate.
It can go wherever you want it to go, why do you need someone to tell you where to put a class?
A lot of people have the wrong idea that, unless you put your classes inside some specific directory grouped by functionality, things will not work. This might be true with other frameworks, but with ASP.NET MVC it's not true. Code is compiled to assemblies.
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.