Where do utility methods go in MVC setup? They are not Models, Views or Controller. They don't belong in those folders. So do is the only right thing to do is to keep utility methods outside your ASP.NET MVC project and put them into a project of their own?
It really depends on how big your project is. If it's just a small project with a few utility methods, then what I normally do is put them in a folder called "Infrastructure" inside the MVC project.
The initial setup you get for an MVC project is only really a guide (with some exceptions), and you're free to add folders and put code in them if you want to.
If there's going to be a lot of supporting code, then a separate project might be cleaner and easier in the long run.
Related
I'm trying to find out if there is a way to use ASP.Net MVC to design a modular web application.
By modular, I mean that I should be able to drop a "package" (which could be made of a bunch of files, I don't necessarily require a single file deployment).
The idea is to deploy additional functionality seamlessly. Functionality could go from tweaking the existing web site (that is the easy part, any plugin architecture would do), up to having whole new site areas.
I'm looking for pointers as to
- if that is even possible
- what choices I have to make w/ regards to view engines for example
- any gotchas I should be aware of
I found one or two references, but ASP.Net MVC moves fast and they might be out of sync.
Any input is welcome (up to and including "don't go there") !
It's easy.
Start with creating a class library with the same structure as a regular MVC project. Make sure that all views are changed to "Embedded" in file properties.
Use an inversion of control container like Autofac and just tell it to register all controllers in all assemblies found in the current directory.
You need to create a custom VirtualPathProvider that looks for your views in all found plugin dlls. You might also want to make the VirtualPathProvider modify the views so that #inherits YouBaseView<TModelName> is added, since Views\Web.Config isn't used for embedded views.
I am thinking about doing something similar, I found this to be a good article to get started: http://sankarsan.wordpress.com/2009/04/12/a-layered-aspnet-mvc-application-part-iv/
What I have done so far is opt for the Castle Windsor IoC container - information about ASP .NET MVC and Windsor is here: http://stw.castleproject.org/Windsor.Windsor-tutorial-ASP-NET-MVC-3-application-To-be-Seen.ashx
I then use the Razor Generator from here: http://razorgenerator.codeplex.com/ so that I can compile views into separate assemblies.
And some code from here: https://github.com/csteeg/BoC/blob/master/Src/Commons.Web.PrecompiledViews to build a view engine that uses the IoC container.
With those two things and a few interfaces that are custom to my application I have been able to drop in "modules" by putting DLLs into a folder and have them appear as tabs within the hosting application.
I'm developing MVC application where I currently have 3 projects in solution.
Core (it is supposed to be for Repositories, Business Classes, Models, HttpModules, HttpFilters, Settings, etc.)
Data access (Data provider, for instance SqlDataProvider for working with SQL Server datastore - implements Repository interfaces, XmlDataProvider - also implements Repository interfaces but for local XML files as datastore)
ASP.NET MVC project (all the typical stuff, UI, controllers, content, scripts, resources and helpers).
I have no Models in my ASP.NET MVC project. I've just run into a problem because of that coz I want to use the new DataAnnotation feature in MVC 2 on my Business class, which are, as said in Core, however I want to be able to localize the error messages. This where my problem starts. I cannot use my Resources from MVC project in Core. The MVC project references Core and it cannot be vice-versa.
My options as I see them are:
1) Move Resources out but this would require correcting a whole bunch of Views and Controllers where I reference them,
2) Make a complete restructure of my app
What are your thoughts on this? Also, Should I just move everything business related into Models folder in MVC project?? Does it even make any sense to have it structured like that, because we can just make subfolders for everything under MVC project? The whole Core library is not intended to ever be used for anything else, so there actually no point of compiling it to a separate DLL.
Suggestions appreciated.
Throw it all into one big .csproj boat and use folders to separate things. Its much easier to navigate folders than separate projects. You won't have to fight namespaces all the time and everything is right were you expect it. You completely eliminate any .sln kung fu when things aren't int he right location or assemblies need to be referenced and you can spend more time coding rather than moving .sln bits around.
Some people say it makes it harder to "swap out an implementation" which is baloney. Swapping the contents of a folder is just as easy as swapping the project.
The MVC source is what made me fond of this approach. They flatten everything out and its really easy to swim around their source code.
I would like to use a WebSite project instead of a Web Application project for an MVC project.
What is the best way to accomplish this and are there signifigant problems that I might run into?
(as a side note, my reasoning for wanting this is because I have graphic designers who put files into SVN but they don't get added to the "project" and don't show up on deployment or deployment testing. My thought was that switching to a Web Site project might prevent this)
You don't need to do anything special if you are not using CodeBehind files (if you're using them, it'll be more complex but anyway, it's an MVC app. If you're using them, don't!). Just take an MVC Web app project and put all source files (*.cs) under App_Code directory of the Web site. That said, I fail to see any advantage for it.
The application project allows you to use the Models folder to embed classes into. This would then be compiled for that web project. A web site does not provide for this directly. It would require that you use an assembly project to maintain all of your classes. Rather than converting from one project type to another (which I am not sure how you wold go about doing that) you can simply attach an assembly project to your web application and not store any classes in the model folder of your application.
Having said this, you should keep your web project as an application as there usually are view specific classes that are required such as a your view model classes that belong in the web project.
I've built ASP.NET webform projects in the past, and when generating Subsonic classes, the teams I have been on have put our Business Layer/DAL objects into a Project.Framework project.
Would that still be a recommended structure, or should the Subsonic classes go directly into the /Model folder within the MVC web project?
It shouldn't go in the Model folder (I think the Model folder should just be used for a Class that is made only for the view and wont be used in the rest of the app).
It should go into a separate assembly Maybe Project.Core or Project.Data
I would not put the Subsonic classes directly in the MVC project. Since you didn't with ASP.NET, there is no reason to change now.
I wouldn't even leave the Controllers in the MVC web project.
You can put them in Model, and move them to their own project later, but its not really any more work to just put them in their own project now, so I would just do that.
Ok, this is possibly borderline-subjective, but I wonder where one would put a simple class that does something within an ASP.net MVC project? I mean a class like the Base36 De/Encoder, that is neither Model nor Controller. Should this always go into a separate Class Library Assembly, or do such Classes have a place within the MVC Web Application project?
And yes, I know that it probably does not really matter, I'm just possibly a bit over careful to learn a new technology the "right" way from the beginning.
I personally put such classes in some common "utils" assembly. Not only does it avoid junking up your MVC project, but such helper classes often find their way into other projects I work on.
You should still have your separate projects where you include your own libraries, helpers and frameworks. You should still see the ASP.NET MVC project as a web project. You don't have to put all your business logic or web helpers in the Model folder.
You should read the article Jeremy Miller wrote recently about separate assemblies. Using the IoC pattern gets you loose coupling in a way that creating a lot of assemblies cannot.