is there any particular directory that i should put my code into in an asp.net mvc project
i have some extentions to the HtmlHelper class. Right now i have it sitting in the Content folder. is this correct? is there a better soluiton?
I usually create a separate project (or projects) for my own code, including my data layer, as class libraries. I then reference the libraries in my MVC web site.
you can put code wherever you want, but typically you want things organised. heres how i do it:
2 assemblies
MyProject.Domain
this contains all my domain code; business logic and entities
MyProject.Web
this contains controller code, views and assets like css/images
Your HtmlHelpers belong in the .Web project because they are mvc related (nothing to do with the domain). You probably want a new folder called Helpers or Extentions. Its really up to you, the key point is to decide where something belongs and to namespace it accordingly
I agree with what everyone else said, here's how one of my solutions would look like:
1- MyProject.WebUI
2- MyProject.DomainModel
3- MyProject.Test
4- MyProject.Extensions
This extensions project is new to me (actually since I knew about extension methods). It usually concludes sub-folders describing what the extension methods are used for, for your particular case, the folder name would be HtmlHelpers. I then reference this project (or its output library when using elsewhere). HTH
If you are going to re-use the same HTMLHelper extensions in different ASP.NET MVC projects, I'd suggest putting them in a class library which is completely seperate from your project.
Related
Lets consider default ASP.NET MVC application folder structure, so it's looks like this:
-App_data
-Content
-Controllers
HomeController.cs
-Models
AccountModels.cs
-Scripts
-Views
My question is: Where is the best place to put Entity Framework Data Model (EDMX) file? Is it Models folder? Yes - we know that good solution is to introduce new Project and reference it to MVC application, but lets forget about this now.
For a small project, it should be part of the Model. For a larger product, the repository and the associated model could be in a separate assembly.
Well this is debatable, but i'd vote +1 for the Models folder.
The only other candidate would be App_Data, but this is generally for file-based databases (SQL Server CE .MDF, for example) and files you don't want served by IIS.
As the EDMX is an abstraction of the database, it should go into the Models folder.
If the project gets bigger, you should definetely move your EF Model into another project. To future-proof yourself from this, make your Controllers access the EDMX via Repository/Interfaces, so when you move the DAL over to another project, all you'll have to do is add the reference and add in the using statements.
I would put the EF-model (aka physical model) always in its own assembly or in a "core" assembly outside of main MVC application. The same applies for your business-logic / domain-logic / domain-services / etc. Separate the non-web stuff from the MVC-Web-Application.
This will help you re-use the core part of your app. For example when you need to expose it as a service, a command-line tool, migration-tool, etc.
Because storing this in its own assembly is so easy and takes you a few minutes I highly recommend doing this for each and every tiny app too.
My opinion is that you should create
a separate project for domain objects, datacontracts etc. etc...
Like MyProject.Infrastructure including many folders like
DataContracts, Model, Exceptions etc.
a separate project for DataAccess wich contains the DBContexts and the Repositories, this way you can easily manage migrations later on
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.
Where do you put non-controller, non-model code, like util classes, extension methods and so on in a ASP.Net MVC project? Maybe there's not a specific place to put it, you just put it anywhere, if so, any recommendation? Any best practices?
if it's a single class i put them in a "Library" folder on the project root. If it's a bit bigger I use a specific folder and if it's something more complex i create a new project in the same solution.
According to the Kigg Sample MVC web project (You can get it from the official ASP.net), they put extension utility classes with a subfolder under root.
Good references for ASP.NET MVC Best Practice
http://weblogs.asp.net/rashid/archive/2009/04/01/asp-net-mvc-best-practices-part-1.aspx
http://weblogs.asp.net/rashid/archive/2009/04/03/asp-net-mvc-best-practices-part-2.aspx
App_Code is intended for such purpose if I'm not mistaken.
Anything stored here (including in subfolders) will be accessible throughout the application.
In VS2015 Community (probably others as well but I've not checked) it's even in the context menu under Add -> Add ASP.NET Folder -> App_Code along with a few others.
My recommendation is to put them where they are used most. So if it is the controller that uses them put it with the controller, and so on.
I am trying to create a .Net Library with few Controllers, and i want to reuse them in Multiple web projects.
I'm half way through, But problem i'm getting is , Whenever i add the library to the new web project , i need to copy all corresponding view files separately to the new project. Whenever i update the library, i need to repeat the steps again.
Is there any way , i can embed View files inside dll as resource , and pass it to "View()" function as an embedded resource.
What i want to achieve is , I want to put controller and corresponding views inside single dll file, so that i can easily distribute/manage the library as a single dll file
( Oneway i already found , is creating custom view class with IView Interface and Render the output directly by writing to HTML Output Writer, But i prefer to use the View file.)
Phil Haack just posted a blog post a few days ago that would probably help you; He's using a database to store the views and ruby to process them, but I would think you could take his prototype and make it work for views stored in a separate assembly fairly easily.
Just a quick glance through the code and I think the magic sauce is going to be implementing VirtualPathProviderViewEngine (See the "RubyViewEngine" class for example) and inserting your ViewEngine into ViewEngines.Engines Collection (see Global.asax.cs).
You can probably use a VirtualPathProvider for this.
The WebFormView type eventually calls BuildManager.CreateInstanceFromVirtualPath. There is not an overload or other function in BuildManager to take input from a stream instead of from a virtual path. Therefore, if you do not want to implement IView yourself, you will need to actually unpack the files to disk so that they can be compiled by BuildManager. You could still distribute your DLL as a single file, but the aspx files need to be produced in order for BuildManager to compile them. See BuildManager help for details.
Check out the ASP.NET MVC View Engine using VB.NET XML Literals project on CodePlex http://vbmvc.codeplex.com
It is a custom view engine originally conceived of by Dmitry Robsman, who is a PUM for ASP.NET at Microsoft. Each view is a VB.NET class and the Namespace (instead of file path) is used to connect Views to Controllers. It's fairly straight forward to copy the content of your ASPX view files into the XML literals in these VB classes. And as classes, they are compiled into the assembly without any extra effort.
If your controllers are C#, then most likely you'd end up with 2 DLLs, but Scott Hanselman has a blog post on getting C# and VB to live together in the same assembly. http://www.hanselman.com/blog/MixingLanguagesInASingleAssemblyInVisualStudioSeamlesslyWithILMergeAndMSBuild.aspx
Take a gander over to codeplex and have a look at the Managed Extensibility Framework
Once your done there...
See what Maarten Balliauw has to say about ASP.NET MVC and the Managed Extensibility Framework (MEF)
Trying to create a MVC User Control in the Release Candidate and I can't see to make one with a codebehind file. The same is true for MVC View pages.
Creating Views in the Beta would produce codebehinds...am I missing something?
Code behind kind of defeats the purpose of the MVC Framework. Functionality should be kept separate from the view, the MVC team felt that code behind pages went against this ideology and therefore removed them.
Your can create a custom helper method to create your control. Also I'm not sure if MVC has view components (Monorail/Castle) but that could be an option as well.
From ScottGu's Blog post:
*Views without Code-Behind Files
Based on feedback we’ve changed view-templates to not have a code-behind file by default. This change helps reinforce the purpose of views in a MVC application (which are intended to be purely about rendering and to not contain any non-rendering related code), and for most people eliminates unused files in the project.
The RC build now adds C# and VB syntax support for inheriting view templates from base classes that use generics. For example, below we are using this with the Edit.aspx view template – whose “inherits” attribute derives from the ViewPage type:
One nice benefit of not using a code-behind file is that you'll now get immediate intellisense within view template files when you add them to the project. With previous builds you had to do a build/compile immediately after creating a view in order to get code intellisense within it. The RC makes the workflow of adding and immediately editing a view compile-free and much more seamless.
Important: If you are upgrading a ASP.NET MVC project that was created with an earlier build make sure to follow the steps in the release notes – the web.config file under the \Views directory needs to be updated with some settings in order for the above generics based syntax to work.*
I answered this question here:
How to add a Code-behind page to a Partial View
Seems this wasn't particularly tricky, and is quite do-able
This answer worked for a Partial 'ViewUserControl' but the same should apply
Ok.
First: Add a Class file with the convention of .cs (i.e. view.ascx.cs)
Second: Add "using System.Web.Mvc;" to the class
Third: Change the Class to Inherit from "ViewUserControl<>"
Fourth: Add the following to the View's header:
CodeBehind="View.ascx.cs" Inherits="Project.Views.Shared.View"
Fifthly: Copy the files out of the solution and drag back in to reassociate the two together
Note: For this to work with a Normal MVC View you just need to inherit the class from "ViewPage"
The whole idea for ASP.Net-mvc was to get rid of the codebehind files...thats why asp web controls didnt matter that most didn't work.But with the changes of getting rid of the code behind comes with a different programming style..The idea is codebehind files are EVIL:
http://stevesmithblog.com/blog/codebehind-files-in-asp-net-mvc-are-evil/
the whole idea is to make sure people remember they are using asp.Net-mvc and not asp.et web pages. take alook at this link ,it explains it a little better:
http://blog.lozanotek.com/archive/2008/10/20/Visual_Studio_Templates_for_MVC_Views_without_Codebehind_Files.aspx
I think this tutorial is what you are asking.. but not really sure what you want..