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.
Related
I am converting a .NET 2.0 Winforms applications to ASP.NET MVC3. The Winforms solution uses several projects for business logic, and the MVC application includes these projects. The projects are also used by a variety of Windows console applications.
The problem is that these projects use System.Windows.Forms.Application.StartupPath to find files they use, whereas for web development System.Web.HttpRunTime.AppDomainAppPath is used.
I would prefer that both solutions use the same projects and that these projects are modified as little as possible as they are large, old, and relatively undocumented. What is the correct way to address this issue?
Right now I am thinking that I would create a new configuration with each project that would define WEB, and then use #if/#else statements to include the correct depedency and to define the return of the getPath() method.
Before you start plaguing your code with preprocessors, you should consider creating an interface IApplicationConfigurator or IApplicationStarter
public interface IApplicationStarter
{
string GetPath();
}
And inject it with a MvcApplicationStarter or a WinformsApplicationStarter depending on your application. You can then have your project libraries have a dependency on the IApplicationStarter interface. It should require minimal implementation on the projects, and you can reuse the pattern for other common dependencies. Look into dependency injection frameworks as it takes this approach into the next level.
This is what class libraries are for. Create a class library project, move all the common bits there, and then have a separate WinForms and MVC project that both reference your class library.
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.
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.
I'm just starting to work with MVC and trying to understand the best practices behind designing an application. In the WebForms world, I typically just created a Classes folder where I stored all of my *.cs files. However, because of the way that MVC uses the folder structure to create different namespaces, I'm not sure that's the right thing to do any more. I can't seem to find any guidance from Microsoft on this topic, so I'm hoping someone here can oint me in the right direction.
Is there a right way to organize files in an MVC app? And, more generally, is there an authoritative place to look for this kind of best practice guidance?
Here's a sample folders structure:
Controllers
Models
ViewModels
Mappers
Views
Repositories
Services
Validators
...
Obviously those layers could be split between different assemblies.
You may also take a look at a sample MVC project structure I wrote.
The MVC namespaces don't dictate where your classes should be kept. However, it makes lot of sense if you store them in proper locations as per their category. e.g. if it's a controller class, you will store it in Controllers folder. If it's a ViewModel, you would store it in a ViewModel folder.
Having said that, I believe what you meant by classes were entities that you use for your business logic. If that's the case, you might want to store them in a seperate class library if you application is big enough and you are creating Plain Old CLR Objects (POCOs) by hand. This is the same as you did in the webforms world.
In case it's not a big application or you are using ORM generated entities like those generated by LINQ or Entity Framework, and not explicitly creating them, you might want to include the .DBML (LINQ) or .EDMX (Entity Framework) files in the Model folder. The Entities will then be inside the auto generated designer files in the Model folder.
Hope this helps.
The only special folder in Mvc is the Views folder (and also the Areas folder but that's an advanced topic) where the frameworks locates view files. Your source code files can go into arbitrary locations. However, the structure that Darin listed is a useful convention that helps different developers working on the same project quickly located what they are looking for
You can also start with a new project using the Empty project template (it's not actually empty) and it will create the basic recomended folder structure for you.
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.