In ASP.NET Webform, App_Code is the standard folder for putting code and using it at run-time. But I think this folder is kind of different in ASP.NET MVC, my question is:
where should I put my code ( Extension methods, Helpers, ... ) in ASP.NET MVC. When I store code in App_Code folder, I can't use them in controller but they work fine in views.
About Entity Framework, the same question, where should I put edmx and tt files? I'm not using Code-First
Update:
After some search, finally I created a new Class Library project in my solution, code is available in all controllers and views. I still don't know why the code in App_Code is not available in the controller
I had the same issue, my class Utility.cs was not recognized inside my MVC project. I changed the Build Action "Content" to "Compile" and that solved my problem.
Hope that helps.
App_Code is necessary in Web Site projects because it has a special meaning. It means "Don't serve these files to a web browser". In ASP.NET MVC, files are not directly served to the browser in most cases, so App_Code is not necessary. You can place code files whereever you want, in any folder you want because these files are compiled into a DLL and not typically published to the website itself.
Using a stand-alone library is also a fine solution.
No one really explains why App_Code exists in the first place. It's the place where you put code files to get dynamic compilation (at runtime). That's the number one reason for App_Code and why it is special. You can put code in any folder you want but you will have to mark it with Compile action to compile while in App_Code that is not necessary, in fact, most files in App_Code aren't even a part of a project.
It does work in ASP.NET MVC projects too you just have to name your code files with .cshtml extension.
I'd recommend starting with this tutorial. It uses EF code first, but you can simply replace the code first DbContext with a normal edmx ObjectContext if you wish (hint: Models folder).
App_Code is specific to Web Site Projects. IMO, its a terrible way to organize all but the simplest of web sites. An MVC project is a Web Application Project, so there is no App_Code and your classes can be defined pretty much anywhere.
Well, try to download some already existing opensource projects. One of them is rather complex, but very cool if you'll get understanding of it - orchard
The best practice is moving this logic to DAL (data access layer) or BLL(business logics layers). Depends on complexity of your application.
For those who don’t want a second project/class library and just want a simple folder for a few c# classes, I propose “App_Classes”.
Related
I want to ensure I follow best practices in the context of ASP .NET MVC 3. I am using the Razor template engine to generate automated e-mails when certain actions are performed on an MVC 3 web application.
I have created a separate class library for the e-mailer and this class library will contain the models that will be used when generating the emails as well as a message factory which will generate the necessary message text using the appropriate view and model.
I am unsure as to where I should be storing my view templates. I would like to store them as CSHTML, as this will allow the developers on the project (who are new to Razor) to use IntelliSense while creating the mail templates.
I don't think I can store them in a folder in the class library as this will make deployment more complicated. If I store them in a folder within the MVC 3 Web Application root, they will be accessible to anyone on the internet with knowledge of the correct path. I now consider two options:
Store them in the app_data folder, but this seems untidy.
Store them in a folder called "EmailTemplates" within the Views folder in MVC. I think this is the best option as you can not browse to it directly (no controller) and our developers can access them easily and make use of IntelliSense.
Is option 2 the best option, would it be a sin to have these mail templates located here? I would then access the files directly through the local filesystem but I am not sure if I will have security issues once deployed to production (perhaps using the app_data folder would prevent this). I would like minimal configuration for deployment.
Thanks!
As usual, there's no one right answer, its all about philosophy and approach, but most important (in my mind) - utility. I.E. if it works, easy to maintain, understandable - why not do it?
I would, in your shoes, put it under App_Data folder - this is by definition where all data that application uses goes. Database is there, configuration XMLs are there etc. So why not use that folder for your purpose.
You can easily access it like this from within your C# code: System.Web.HttpContext.Current.Server.MapPath(#"~/App_Data"). I don't think any other (created by yourself) folder will be any better or worse ... its just App_Data is there specifically for these purposes, but it doesn't mean you cannot do something else, that makes sense in your application.
Hope this helps.
After doing more research and some experimenting, the Views folder seems to be the best place for my email templates. Here's my reasoning:
The email templates will only be used by the web application and nothing else.
The application pool the MVC application will run under, will at the very least have access to read the folders within the Views folder. This means I don't need to cater for any special permissions for folders during deployment. (Although this is true of the App_Data folder as well).
IntelliSense does not work from within the App_Data folder but does work within the Views folder. As the developers on this project are new to Razor, IntelliSense will make things easier for them. Also just makes development of the templates easier.
Although I created a separate project for the template mailer, one
can store the models for the mail templates with your MVC models as
well.
I have a question about organizing .resx files in mvc3 application. So far I have managed to do the following:
Creating new class library in a solution for resources and adding resources for two languages. Everything works fine when I have for example:
Resources.resx //default language
Resources.en.resx //english language
But I want to have such organization in my class library:
DefaultLanguage foder
- Resources.resx
en folder
- Resources.en.resx
I want to organize resources by folders. I think it is more appropriate for people who will translate the site and it is also more maintainable. When I organize resources in such a way the web page returns an error...cannot find error. Am I missing something? I know that you should not have folder name in namespace because that would mean that referencing resource in View is dependent on folder name and this is not correct.
The point is I would like to have the same behaviour of resources wheter they are organized in folders or not...
By the way: I check on the web and could not find any appropriate solution.
Thank you for your answers!
MVC3 uses ASP.NET resource management. See ASP.NET documentation for details. If you want to rely on ASP.NET behaviour and generated strongly typed classes, then you must keep resource file from default language and other language specific resource files together.
To have the same tree structure that you suggested, then you have to implement your own resource management. You probably don't want to do that, because (at least some) resource editing tools rely on that behaviour.
On our projects we have one resource (and his translations) for each view. They are in folder Localization within MVC3 project. Inside we keep the same tree structure as is within Views folder. This is more or less the same as ASP.NET local resources are organized. Common strings are kept in one .resx file on root of Localization folder. This ensures maintainability.
To keep your people that will do translation happy you have to pick good .resx editing tool.
I'm following this link, compile razor files into separate dll, and can get it to work except I can't figure out how to access JavaScript, CSS, and Images embedded in the dll.
Has anyone used this approach? It seems very promising. Thanks.
The technique presented in this article is for embedding razor views into separate assemblies. It doesn't allow you to do so with static resources such as images, js and CSS. For those type of resources you will have to implement a custom solution. For example you could write a controller which, given a resource name, could read it from the assembly (GetManifestResourceStream) and write the stream to the response. Then you could simply generate links to this controller action in your views (Url.Action) and pass the resource name.
You can use my EmbeddedResourceVirtualPathProvider which can be installed via Nuget to load all kinds of resources from referenced assemblies, and also can be set to take dependencies on the source files during development so you can update views without needing a recompile.
We are working on an ASP.NET MVC 3 project and taking advantage of Razor syntax to resolve paths and what not.
We are also employing a UI design team who is responsible for maintaining the design of our pages through the use of CSS and modifying the HTML in the cshtml pages.
The problem is, they work exclusively on Mac laptops without access to a web server or a .NET IDE.
Initially, they were just providing us a straight .html file along with a .css file and we were manually merging in their work into our ASP.NET solution (e.g., replacing paths with Razor markup, etc), but as the project grows and we become more involved, we are looking for a solution that will save us from these manual merges.
I was thinking I could create some kind include script that would rewrite the paths depending on whether the UI designers were editing the file, or the .NET devs, but this seems archaic.
Anyone out there been in this situation before?
Razor is a templating language, and a pretty small one at that. Could your UI team familiarize themselves with enough of it to deal with their own links? I'm sure they are familar with your view hierarchy since they are going to be building it, so it shouldn't be much of a leap to explain how controller and action paths work.
Razor files can be edited outside of a .NET IDE just fine...any old text editor will work since it's not like there's anything you have to compile. You could provide them with an instance that they could copy their files to via a shared drive (cifs) to test them on. I don't see any reason for your UI team to be required to use Visual Studio.
You could just rename your .cshtml file to .aspx and reload it in VS and design away. when you are done, rename it to .cshtml
Examples given are from Kohana 3, but the question is not limited to the framework.
I've always put my assets in a file structure like this
application
- classes
- views
assets
- css
- js
- swf
- images
-- layout
-- content
system
- classes
I've started reading a few forums where people always mention their assets files are placed in the views folder. This makes a lot of sense to me as these files are tied to the views quite closely (being included by markup). Plus, it will unclutter the docroot.
What is the preferred location of a site's assets? If I do place them under an views/assets folder, where should the actual template files go... under a separate folder like views/templates ?
For ASP.NET MVC
The project template gives you the folders ~\Content and ~\Scripts with the latter containing JQuery.
Why not follow this model, adding additional folders below these if they would otherwise get too many items.
I would stick to the project template unless there is a very good reason to override it (and also override the logic to find views and controllers).
I tend to place mine in the web root (wherever that's defined by the framework) so that I can reference /assets/img/myimage.jpg (or an analogous CSS/JS file, etc.). As Richard suggests, though, I do this because I'm sticking to the framework convention. I'm not familiar with Kohana, but the frameworks I've used extensively all place assets in the web root by convention.