I have a VERY large website that has classic asp and webforms. I have successfully added MVC and it is working great but... the number of controllers/views is going to massive and I need to organize them.
I would like to use Areas but I cannot find any examples of it working.
I have placed my "Controllers" folder in the "App_Code" folder (if there is a better way, please tell me) and would like my structure to have 2 more levels like this:
App_Code/Controllers/Level1/LeveA/FooController
App_Code/Controllers/Level1/LeveA/BarController
App_Code/Controllers/Level1/LeveB/ThisController
App_Code/Controllers/Level1/LeveB/ThatController
and want the views the same way:
Views/Level1/LeveA/Foo/Index.cshtml
Views/Level1/LeveA/Foo/UpdateFoo.cshtml
Anyone have any idea how to set this up?????
*** This is a web site not a web application, that is why I put the controller in the App_Code
Related
I have been looking for an solution for structuring my MVC5 project, but have not found anything yet.
What i look for is. I have an Main Website, which off-course has it's own Views, Scripts and Controllers, but what is special is that i like to have sub Website projects which add an menu point in the main page, but the sub website also contains it's own Views, scripts and Controllers( I have tried to draw a picture of what i'm talking about ).
The point of this is to have an structured in a easy way. But also to reuse the same views in a framework way.
You should be able to define an area in another project, found an article that explains in detail how it is done in MVC3, it should not be very different in later versions since areas and routing haven't changed a lot.
http://nileshhirapra.blogspot.no/2012/02/aspnet-mvc-pluggable-application.html
Update: you do not actually need to set up the project in the Areas folder, but you need to copy all content like views and scripts/css into there before being able to use it in the main application.
If you want these sites to actually be separate websites but only look similar, then that is what you'd need to set up. You'd probably want to decide on a single-sign-on scheme for that.
I'm looking at this MVC WebApi starter kit (for Angular/TypeScript)
Ignoring all the client side code, I noticed the author has made a WebApi that is extremely bare bones. Has has taken out most scaffolding including _ViewStart.cshtml, _Layout.cshtml, and forgoed the convention of controllers in Controllers folder and views in View folder under subdirectory with same name of controller, etc.
He added some interesting Routing and Validation classes that I havent seen before in a Core folder and put controllers in Api folder and Views directly into Views folder with an Index.cshtml at the root.
It's very clean and barebone project structure for a standalone web api that will do nothing except serve data to a client heavy application. I kind of like it this way but before jumping ship I'm wondering what drawbacks this approach has and if I'm actually giving up any core features of the framework by doing it this way. For example, clearly MVC Areas are being given up here in favor of flexibility to create your own view folders structure and seperation of application sections (I'm okay with getting rid of MVC Areas I rarely used them anyways). Another thing is I don't think a Controller action method can return View() and it will find it in the Views folder by convention of the controller name. I'm also okay with that since I will only be serving JSON data and will use 100% client side templating.
Are there any other core features that are being abandoned that I'm missing that may make me regret going with this project structure?
When I create Web APIs that are hosted in IIS, the only files in my web application are web.config, global.asax and global.asax.cs. Everything else is not required.
Take a look at this template if you haven't already before you decide how to structure your ASP.Net MVC / Angular project:
http://visualstudiogallery.msdn.microsoft.com/5af151b2-9ed2-4809-bfe8-27566bfe7d83
You can always add components into your project later, so I wouldn't seat it too much. I like to start with a lean/mostly empty project first and add things myself so that I fully understand what I'm adding.
i want to integrate mvc2 into an existing webforms project. to get this work, i found all information online.
now i have the problem that mvc just works when the controller and views folder are placed in the root, but i want to have a specific folder (like 'mvc') so that the controller and views folder are placed like this:
~/mvc/controller
~/mvc/views
is this possible or do i have to use mvc area to solve this issue?!
thanks for your help!
best regards...
If you want to group all of your MVC work together, I would use areas to accomplish this.
I think it is possible though to override the View Engine to point the default root to a different folder. This is detailed in this post.
Something to think about before doing this though is, are you planning to eventually migrate your WebForms to Asp.net MVC and remove your WebForms work? If so you might be better keeping the root Controllers and Views folders in the project root.
Here is what I want to achieve, I want to separate AREAs of ASP.NET MVC as pure single DLL.
Blog.DLL
Forums.DLL
FAQ.DLL
Each of them are individual ASP.NET MVC Area, with its own default CSHTML or ASPX pages. Installing, migrating and maintaining lots of pages including resources, javascripts and so on are real pain for long run. As most of these will hardly change.
My final website will be like this.
\MvcApplication
\bin
\MvcApplication.bin
\Blog.dll
\Forums.dll
\Controllers
\..
\Models
\..
\Views
\..
\Global.asax
\Web.config
Without adding any thing, just dropping Blog.dll, my application should support /blog and all its pages. If I want to customize something, than I can add area, and add only cshtml pages..
\MvcApplication
\bin
\MvcApplication.bin
\Blog.dll
\Forums.dll
\Areas
\Blog
\Views
\Shared
\BlogLayout.cshtml <-- this will override the look
\Controllers
\..
\Models
\..
\Views
\..
\Global.asax
\Web.config
This will help in reusing ASP.NET Area Plugins, by simply dropping the dll in bin folder. However web.config may require some changes, but most likely we will save configure values in database and only thing needed will be "Entity Framework connection string" in web.config.
My challenges (Questions)
Is it possible? It sure looks to me, but will there be any reflection/permission issues?
How do I include cshtml/aspx views within one DLL? Probably compiled versions? I have seen couple of text template based View Engines on codeplex but I am little confused on how to actually use them.
And how do I get ViewEngine to first check if physical directory file exists or not and then look into cshtml/aspx within the dll itself as resource file?
You may take a look at the following article which illustrates how a custom VirtualPathProvider could be used in order to retrieve Razor views that are embedded into separate assemblies as resources.
Maybe worth looking at portable areas from mvccontrib. I haven't used them since MVC 2, but found the following SO question by someone having some problems using them with MVC 3, with some possible solutions: ASP.NET MVC 3, Razor Views, and Portable Areas
MvcCodeRouting supports what you want, plus many other cool stuff. Check out this post about ASP.NET MVC Plugins.
I'm looking for a way to reference a shared external _layout.cshtml from MVC 3 and Razor.
A little back story:
We have multiple developers. All of them are working on separate MVC applications that all need the same look and feel. All these applications will be deployed to the same site for example
http://www.example.com/App1/
and
http://www.example.com/App2/
The look and feel will be generated by the CMS and dropped into a different folder
http://www.example.com/Layout/_layoutExt.cshtml
I've tried
MasterName = #"C:\inetpub\wwwroot\layout\_LayoutExt.cshtml";
But it gives me the error that it can't find the file
The view 'Index' or its master was not
found or no view engine supports the
searched locations. The following
locations were searched.
My eventual solution was to use Symbolic links (or junctions or hard links) to link the needed file into the view folder. This way the CMS writes to one location and my app reads from another. Not the clean solution I was looking for.
You'll probably need to make your own view engine that support reading file outside the web application home directory.