How can I go about separating my MVC project into UI specific (JS, CSS, Images, Fonts, and maybe Views) and Controller/Model specific (Controllers, Helpers, Models, and may be Views). Since our front-end developers work mostly independent of Visual Studio, I was looking for best practices in separating projects. Any pointers or sample projects?
This is how we finally ended up doing it.
Create a separate visual studio project called SolutionName.Client (this is where all frontend js and scss files go)
Create you MVC project called SolutionName.MVC (this is the asp.net mvc project)
Using Grunt.JS write tasks that compiles all js and css files and drops them to SoltuionName.MVC/Content folder
Similarly write tasks that drops all Views (razor files) into SolutionName.MVC/Views folder.
In Project build settings, add a pre-build tasks to run grunt task.
This setup took few hours to get it working but it is now quite useful.
You can easily do this and I've done it for each of my projects in MVC as well.
One project has your Controllers, ViewModels, and in my case, any custom logic related to Dependency Resolution for MVC and custom classes related to security authentication with MVC. Basically any code that touches the MVC framework core and is not involved in rendering content.
The other one has pretty much everything that you use on the client-side, and code needed for the front end. Which in my case, code-wise, is very minimalist and included some code for Glimpse and Elmah. The rest is your Views, Styles, Scripts, static content like downloads, etc.
As for the files in App_Start, My views project has Bundles, Filters, and obviously any HtmlHelpers you may have, custom css transformationslike for LESS.
My Controller's App_Start has the RouteConfig. These aren't necessarily critical it's just the way I ended up organizing mine and really depends what aspects you need access to during the startup of those components.
I will say that to save yourself time, in your Views/web.config file, add a namespace entry for your Company.Project.ViewModels namespace so that it's done in one place and you don't have to add it to each view, as this namespace would reside in your Controllers Project.
Your project with the Views will be your startup project. Just make sure in the global.asax your calls to the FilterConfig, RouteConfig and BundleConfig all resolve correctly.
It's fairly easy to do, my recommendation is to try it yourself and split it out the way you want and if you have problems come back and ask about the difficulties rather than looking for a step by step guide.
Bottom line is, yes it's possible and yes it works,
Related
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'm currently evaluating Durandal for use in an enterprise ASP.NET MVC application.
However the default conventions used by Durandal seem to conflict with the MVC conventions I've grown accustomed to.
The HotTowel MVC template by John Papa is great, but this too seems to "do away" with MVC conventions in favour of Durandals by putting things in an App folder.
A couple of the issues I have with these conventions are:
Views are potentially split across two locations (/App/views and /Views).
Scripts are also split across two locations (/App/durandal and /Scripts).
Views are not in the default MVC locations for the RazorViewEngine.
I would prefer to keep each element contained in the appropriate MVC conventions e.g.
/Controllers/
---- HomeController
---- AdminController
/Scripts/
---- durandal/
---- viewmodels/
-------- Home
-------- Admin
/Views/
---- Home
---- Admin
My questions are:
Is it possible to configure Durandal to achieve the above (or something similar)?
Is it wise to venture away from the default Durandal conventions?
What are the potential issues in doing so?
1. Is it possible to configure Durandal to achieve the above (or something similar)?
Yes, you can have any folder structure your heart desires. Durandal does not impose any folder structure on your application but it does have a default convention which is completely overridable.
If you are using Durandals router then you will want to look into how to configure it to find modules. There are many ways of doing this, I prefer to create my own convention by overriding the router.autoConvertRouteToModuleId.
If you are not using the router plugin then you will have to manage the uris for your modules yourself and this is done by following requirejs' convention and using this convention along w/ durandals composition module.
Also, you can override how it finds the views to bind to your modules by overriding the viewlocators convention. Durandal provides an very simplistic way of structuring small applications right out of the box but if you need to build larger applications then it is recommended you create your own conventions.
2. Is it wise to venture away from the default Durandal conventions? 3. What are the potential issues in doing so?
So, there are the conventions of how to discover modules and how to discover views which are completely overridable. And I recommend you do override these and choose a way that suites you best. But, as for placing durandal inside your scripts folder as you have listed above I dont think its a good idea.
The reason I dont recommend this is because I see the scripts folder as a place for all your third party scripts that are NON-AMD modules. This is because Durandal also comes with an optimizer.exe which makes minifying/compressing/uglifying all your html/css/js (amd) files into 1 file.
If you keep your entire application under an app folder and then have the durandal folder inside your app folder the optimizer just works because it lives inside the app/durandal/amd folder. So, when you execute it, it will transverse up 2 directories to your app folder and then scan every subfolder to create a app.build.js requirejs optimization file.. and then it will compress your entire application to one file for you.
This beats having to hand edit an app.build.js file everytime you add a new file to your project. Sure.. there are other tools out there which can do this too.. but you will have to spend time learning their api and how to configure them. If you dont feel like devoting the time to learning something like grunt then this optimizer is kick ass. Personally, I like the ability to just double click something and have my whole application built for me.
As for placing all your third party libraries which are non-amd in a seperate scripts folder I would look into compressing those seperately like using MVC's bundling. The reason I would bundle those seperately is because you know those files arnt changing very often and if you bundle those into a seperate js file they can be cached by the browser seperately. Whereas if your spa is changing, which it it probably will.. then you want the browser to cache that seperately so it only has to re-download your compressed application.
What we do (this is what I have seen Rob doing too:) is that to create folders inside the /App folder depending on the functional areas of the app. Then just create view and view model file inside these folders.
Trick is to have a "viewUrl" property in each view model to tell durandal which view to use.
This way of structuring the application is useful for large projects where there are many views/view models ; avoids confusion when your project grows.
define(['durandal/app', 'durandal/system', 'plugins/router'],
function (app, system, router) {
var vm = {
viewUrl: 'myfolder/myview.html',
};
return vm;
}
);
You can still use viewLocator.useConvention(); when you bootstrap your application; durandal will still find the view as long as you have viewUrl property.
ok, i know there are a lot of posts online that specify how to do iterations with MVC.
my question is slightly different. when i used to do iterations using WebForms, i was creating one thing only and finishing that one thing till the end which was including the deployment on production.
for example, i was creating a webpage and deploying it, then i create the second page and deploy it. so .dll files were added to my bin folder while the previous dlls remain untouched. at the other hand, when i was making a change latter on, there was this one file that needed to be replaced on production.
now here is the question, how can i acheive the same thing in mvc? beause it just doesn't deploy each page into an individual dll. each time that i add something i have to redeploy the application dll which is not really wise! i played around with deployment options in visual studio but no luck!
There is nothing preventing you from putting controllers and other code in separate assemblies and dropping them in an existing application. Like any ASP.NET based application an MVC application will automatically restart if you add or modify any file in the bin folder or modify web.config.
If you're using Razor you can use RazorGenerator to generate code for your views and compile them into the same assembly.
You may need to write some additional logic though to get routes, model binders etc. wired up correctly.
For a more structures approach to compose the application of separate modules, you may want to look into portable areas. This is an extension to ASP.NET MVC that allows you to package the entire module (including views, css, js etc.) into a single assembly.
First thing, you have to work on the title of the post, it does not match the content of the post.
In asp.net mvc u can choose to deploy only what changed. I.e. If you only changed the .cshtml file, then you can just replace it with the file in production. However if you change any controller class (C#/Vb code), then you will have to upload the web project dll file too so that this new changes are available in the production env
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've got the following project setup
Project A (main)
Business
Data
View (asp.net mvc 3 project)
Project N
Business
Data
View (asp.net mvc 3 project)
How can I call from Project A the View in Project N and from N back to A. Essentially what I'm trying to do is package each Project N to have its own individual MVC as it comes from different sources and plug it in to the main project and then just have it navigate to the correct view.
Can this be done? Or is there a better way to do this?
You could write a custom virtual path provider. Here's a nice blog post which shows an example of such a virtual path provider allowing you to embed Razor views into assemblies as resources and reusing them in multiple applications.
Unfortunately without a custom virtual path provider, you cannot cross reference views between multiple ASP.NET MVC applications. This simply is not allowed by the default provider which looks for views only inside the current application.
I do sugest another approach if possible. if I understood correctly, those projects are somehow ike plugins but they are not standalone applications.Also they now about each others so they are coupled. It's, let's say tricky, but I would use only 1 asp.net mvc project (the web ui). All the UI bits which belong to other projects I'd make them helpers (pretty much widgets). This means, that each project contains only the helpers which will be used to construct a view.
I think it's a bit of an architectural problem if you only want to keep the views in each project just for the sake of hosting them in a different assembly. Going the widgets' way it might seem mkore work, but I think you gain the most control and the separation level you want. The only thing is you don't have full Views defined, but why you would want to have full Views (partials, layouts) in separate places if they will be used in one place only?!
Now, if each project is indeed a plugin, independent of other plugins, then going with compiled views is the best way. But if Project B knows about the view of Project N, then I think the above solution is more suitable. That or the whole app is too over engineered. Separation is good when it doesn't create a whole new jungle to navigate it.