First of all, I do understand, that MVC 3 default template's Content folder is not a mandatory css/img/etc. store folder.
I still like the concept of Content folder to be a "reference-able" storage location for images and style sheets and other possible stuff (I also place entire jQuery custom controls into Content's sub folders with .js files in them).
I haven't used MVC Areas thus far in my projects, since I didn't have a complex enough one's. Now it's time.
And I am thinking about placing a separate Content folder in each Area. Will it work? Is there something "bad" that can turn out of it? Like me not being able to reference resources in it via ../Content/MyControl? Or is MVC Area just like a root of the project, but a separate one?
The area is almost just like a separate project (but not really). You can either use
Url.Content("~/Areas/AreaName/Content/FileInfo");
or
<link type="text/css" src="RootOfSiteInfo/Areas/AreaName/Content/FileInfo"/>
There should not be any issues not being able to reach the static content, though personally I leave everything in the root content folder (single point of storage) since many times CSS and the likes are shared in our projects across areas.
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 am just new to MVC, we are building a massive system and have alot of namespacing in our site.
Where is the standard place to store files (CSS, Images, .JS) etc?
Would it be good to put them under the Content folder in sub-folders to their namespace or drop them in with their respective parent files or both.
The default project structure includes a Content folder for CSS files and a Scripts folder for JavaScript files. A lot of people use this existing template, especially since a lot of Nuget projects may rely on this.
I personally like to put all of the content in a Content folder, and have a subfolder under this named Css and Scripts. It's really a matter of preference though. Do whatever is consistent and well-organized. That will be the key to making the application more easily maintainable.
Its better to put it in saparate folder as Script(js file) at root level.
Add sub folder in content folder for Images and Css etc.
we can also create multiple controller and views for each section of your project.
like for login section you can add Authentication Controller.
we can also use Helper class for adding general function and use it in every where.
you can see following link
http://msdn.microsoft.com/en-us/library/dd410120(v=vs.100).aspx
I have ASP MVC 4 website.
I use ResX files to localize the site to different languages.
In one of my pages I display localized HTML content (case study) that has images in it.
The whole localized content is stored in a file and the ResX file reference it. This works great.
The problem is how to reference the images from within the localized content?
The images are stored in ~/Content/Img1.jpg (and so on).
For now I've simply put /Content/Img1.jpg but this will not work so good if the website will be deploy to a sub-directory and not the root domain.
Thank you,
Ido.
I think that if you give the same name to the pictures, and this pictures are already embedded in the resources, then you don't have to do anything else, just change the Culture and UICulture as always. If they are different then you might want to see the exact name by inspecting the resources file after compilation. And if your content always references the same static images, it shouldn't be a problem to put the normal path as you always do. The reference that starts with ~ will always start from the root and the structure can be ~Content/en-US/picture1.jpg for example. Let me know if it helps,
In asp.net mvc (4), out of the box, views go into Views folder, and then grouped by controller in subfolders.
Controllers go into Controllers folder, (View/Edit/Input)Models go into Models folder, etc.
I do like the way views are organized. I do not, however, like breaking the rest of the MVC pieces horizontally.
My question is, what would be downsides of leaving views organization structure as it is, but group other classes by controller (i.e. by use-cases). E.g.:
/Home
HomeController.cs
IndexViewModel.cs
IndexViewModelBinder.cs
/Messages
MessagesController.cs
MessagesApiController.cs
MessagesViewModelBinder.cs
MessageViewModel.cs
MessagesListViewModel.cs
/Views
/Home
Index.cshtml
/Messages
MessagesIndex.cshtml
MessageDetails.cshtml
All that matters is the arrangement of the View files because they're accessed at runtime. Everything else is compiled into the assembly so the physical location of their source files is irrelevant.
Like you I find the default arrangement a bit awkward for larger projects, so this is how I lay out my current projects:
~/
/Areas
/DefaultArea // I always use areas, even when there's only one, because it simplifies things when adding additional areas.
/Controllers
FooController.cs
/Views
/Foo
FooView.aspx // Yes, I use WebFormView. Just a matter of personal preference
FooEdit.aspx
FooModels.cs // this file contains my ViewModels
So basically, I put my ViewModel classes in the same folder as the views rather than putting all the ViewModels together (which makes less logical sense). I was tempted to put my Controllers in their views' folders, but I decided against it.
I've found no downsides to my approach so far (been using it almost 2 years now).
I generally like to avoid areas where possible as it creates some issues with routing.
I think your structure is completely fine (and superior to the default MVC/Web structure of separating code based on "type" rather thank "function").
All I would suggest is that you only keep your "web" .cs files in the web DLL (e.g. Controllers, ViewModels, Binders, etc) and have the same structure in separate DLL(s) for Domain / Services / etc layers so they can be reused / tested separately if/as required.
Out curiosity I was wondering if there was a logical reason to have the Scripts folder not a sub folder of the Contents folder in an ASP.NET MVC project. The Contents folder typically contains your style sheets and images and for some reason it would seem natural to me to also include the Scripts folder in there as well.
Possibly because scripts could be denoted as providing more functionality than style and design items, so it could be considered a portion of your business logic.
The scripts and content folders are containers for client-side consumed files. They don't affect your MVC applications in any way. You can rename and move them around as you see fit, provided you update the URL references to them to point to the new path.
Having said that, I personally tend to rename these to js and css mostly because this makes my URLs shorter and easier to read and understand.