I have a standard MVC 5 project created from the VS Template. Now I want to move the Account related controller and views to different project so it becomes a module. (That way it can easily be include/excluded from the site.)
I have been able to put the Controller in another project and reference the project, but the account views are not located at runtime.
How do I tell the View Engine to look in the other project for the account views?
After a lot of working with this, it seems that having views in a different DLL may not be the best pattern. First, while it can be done, it requires some extra plumbing. Second, it seems to violate the MVC pattern in that now you have two MVC patterns working side by side. What has worked for me is simply moving the Model part to a different dll. In other words, the plugin becomes a Model provider which is simply used by the Controller and then combined with the view. This is very easy to work with, requires nothing special, and yet separates the responsibilities.
Related
Is there any functional reason of the default files structure on new ASP.Net MVC Application (Grouped by controllers, model, views etc. ?
Otherwise I would structure it in a way that would be more convenient for me.
Thanks!
Technically, you can put models and Controllers anywhere, since they're just code files that get compiled into a DLL. Other files, however, have stricter location requirements if you want to take advantage of the conventions that MVC asssumes.
Strictly speaking, you can place views anywhere. However, doing so has a number of consequences. You must specify the full path to the view in your View() method, and if you don't put views in the ~Views folder, then it's possible for people to download them directly (which you don't want).
In general, MVC works a lot more smoothly if you follow the conventions. If you go your own way, you lose a lot of automation and productivity.
I have been working on a large ASP.NET MVC 3 application for a few months now. It wasn't until late in the project that I realized that my controllers were HUGE! Part of the problem with these controllers being huge was that I couldn't unit test them.
I've since split the responsibilities of the controllers into four tasks (in my mind):
navigation
converting IDs to data objects
building view models for display
general-purpose business logic
Since some business logic is shared across client- and server-side code, it doesn't make sense to mix it in with view model builder logic. So, I immediately see the need for at least two projects: view model builders and general-purpose business logic.
I realized that navigation should be the responsibility of the controller, so that logic stays in the MVC project.
I am a little torn about which project should be responsible for converting IDs to data objects. Originally, I had made this the responsibility of the business class/view model builder class. However, I think I would like these classes to work primary with fully-constructed objects. So, I am not sure where in the code this conversion should take place. It doesn't seem to matter where I do the conversion, the code becomes duplicated. I have been thinking about creating adapters in the respective projects that do these conversions and then call the actual business class/view model builder class.
Has anyone worked in an ASP.NET MVC project that has grown beyond a single project?
How is logic broken out to keep the size of controllers down and keep code testable?
Has anyone worked in an ASP.NET MVC project that has grown beyond a single project?
Yes.
How is logic broken out to keep the size of controllers down and keep code testable?
By putting controllers on a diet.
I am trying to find the best way to layout my MVC 3 project. When searching online I came across a suggestion that basically said right click on project and add area. What this did was create an area folder with same controller/view/model structure in the same project. This is not what I want. I want the flexibility of having separate projects. I will keep only the views in the main web project. Everything else in a separate project.
Towards that attempt I created a separate project for my controllers. Now I am stuck with pointing a controller action to a view. In all the online examples it was right click and add view. This being a class library project I don't have that flexibility. Where am I going wrong?
All examples that I have found including the ones I have gone through on Asp.net basically explain how to create study applications, which is only good for learning purposes. A large commercial application can't possibly have all the views/models/controllers in one project. Or is that the way it is supposed to go in MVC? I am not sure if doing everything with mouse clicks is also a good idea. In the webforms world also there were a lot of study-for-beginners applications that used mouse clicks to create basic CRUD applications, but in real commercial projects, we never used those methods.
What are your thoughts, guidance on this?
Thanks for your time...
MVC is based on a convention; the convention is you put all the views on /views, the models in /models and the controllers in /controllers. You can change the convention but it will not make your life easier.
From a conceptual point of view this does make sense. If you keep all domain logic and data access in separate projects all you are left with is the web related stuff, your controllers, view models and views. That's your MVC project.
Note that if you want to split off parts into separate projects you may find portable areas useful.
I don't see why you can't use the built in generators as a base for your views and controllers? Nothing says that you have to leave them as generated. I personally thinks that's it's really nice to get a base generated for me (with mouse clicks).
The MVC project is just a UI layer. It's madness to put logic in it for large scale applications. It's therefore usually fine to have one project for all the UI. It actually makes it easier to get an overview of the UI.
That said, there are ways to get a plugin based solution where you can move the controllers (, models and views) to class libraries. But it's not easy.
You need to create a virtual path provider (to find the views)
Make all views embedded
Modify the project file to get the "Add view" dialog etc.
Use areas (makes it easier)
Tell the BuildManager that your plugin DLL exists.
You also need to modify the virtual path provider to access the views from your plugin folders if you want to be able to modify the views during runtime in visual studio. Any change would otherwise require a rebuild of the plugin DLL.
Update
Video for MVC2 (MVC3 areas works the same): http://www.asp.net/mvc/videos/mvc-2/how-do-i/aspnet-mvc-2-areas
Do note that that video is for areas in the same project. Having areas in separate class libraries are more complex. The easiest solution is to use the portable areas as suggested by someone else.
Why keep only your views in the 'main web project' - I think you are missing the point with MVC.
It's the controllers that are your 'main web' part. They are what your users request and post back to, not the view.
The view is only there to provide a means to layout HTML for the controller to push to the browser.
The Models which I think should really be ViewModels, are there to provide substance (i.e. real data) for your views.
So you can see that the MVC layout really wants all three of these to be grouped sensibly together. Controllers interact with your user, get the view (the layout) and populate it with your ViewModel/Model (the data). This is your user interface, all three parts of MVC (if you go with the ViewModel anyway) are only for UI.
Where the data comes from, your real models and whatever you want to do with it can easily reside in a dll somewhere or on the other side of a set of web services or whatever.
i want to develop a simple CMS.
i want to add the ability to add modules to the CMS.
what need to be the architecture for
such a CMS?
a solution and then a mvc project
for the site and another for the
admin? or one project with area for
the admin?
in mvc each of my modules will have a controller,model and views. if i will put all in one project, then i will mix of all module ,each module will be in 3 folders (controller,model and views).
how i need to arrange them so my code will be nice and clean?
Since you are only separating by type of user, you can surely (and easily) include in one project. all of your Admin controllers should have [Authorize(Roles="Admin")] on them to limit them only for the admin. Mixing them is fine, other applications mix user roles in an application on a regular basis, just limit the difference by security (and dont use url restrictions in your web.config - use the [Authorize] attribute on your controllers instead!!
If you expect the differences in both applications to be huge then you can separate into another project, but I'm imagining you can get very good reuse by including them in the same project.
How to architect this is a very very broad question. For a basic project some include everything all in one project. I prefer to break out all my models and data access code into a separate project and try to code to interfaces as much as possible for unit testing purposes. I think that is all a bit beyond the scope of the posting here though. To start - work with the mentioned attribute and I think you will develop. Start unit testing early and I think that will help steer you into the right direction. Also read up on dependency injectiom , unit, ninject, etc for ways to dynamically bind to your implementation classes as this makes your unit test go quite a bit smoother as well.
I've been puzzled by what I consider a contradiction in terms: ASP.NET MVC claims to be furthering and supporting the "separation of concern" motto, which I find a great idea.
However, it seems there's no way of separating out controllers, model or views into their own assembly, or separating areas into assemblies.
With the fixed Controller, Model and View folders in your ASP.NET MVC, you're actually creating a huge hodge podge of things. Is that the separation of concerns, really?? Seems like quite the contrary to me.
So what I'm wondering:
how can I create an ASP.NET MVC solution that will either separate out controllers, the model, and the folders full of views, into separate assemblies?
how can I put areas of ASP.NET MVC 2 into separate assemblies?
or how else do you manage a large ASP.NET MVC app - which has several dozen or even over a hundred controllers, lots of model and viewmodel classes, and several hundred views?
I think you're looking for Areas in ASP.Net MVC 2. There are some things to uncomment in the CSProj files, but after that it will copy the views over when you build. I don't think there is any requirement that the Controller or Model classes be in the same assembly as the views.
Walkthrough: Creating an ASP.NET MVC Areas Application Using Multiple Projects
Controllers: AFAIK you shouldn't have to do anything special to throw controllers into their own assembly. At the very most all you'd have to do is override the GetControllerType method of your ControllerFactory.
Models: Zero restrictions on where you put your models. Although this is frowned upon I regularly use persistent objects from an Nhibernate/other ORM layer or WCF/service layer DTO thats are located in a separate assembly as my views. This works the same way using WebForms.
Views: Views in a separate assembly must be marked as embedded resource and then you must use a custom VirtualPathProvider that knows how to get the views from an resource instead of the file system. views from an resource instead of the file system. Again this is the exact same technique you would use for WebForm development.
Regarding mcintyre321 and his Portable Areas answer: The linked project does barely anything custom and simply wraps up the existing MVC 2 extensibility points into an easier to use abstraction. Its barely "custom" and more syntactic sugar.
You manage a large MVC app just like you'd manage any other large app. I dread opening up a 500 page WebForms project because you never quite know whats in each of those code behinds. With MVC distinct functionality is mostly within its right place. Its not contrary at all.
Separating code into separate assemblies is orthogonal to separation of concerns. Where the code lives is not a "concern". Separation of concerns has to do with responsibilities and direction of dependencies of various components. For example, Views are responsible for rendering the output, and the controller knows about the views, but the views don't really have intimate knowledge of the controller.
Likewile, Models don't know anything about either views or controllers, but both views and controllers will know about the model.
However, back to your question. As jfar points out, moving controllers and models into another assembly is trivially easy and will work. Moving views into another assembly is trickier. Embedded resources with a custom virtual path provider is one way, but not one we generally recommend for a high performance site. But if it meets your needs, go for it.
MVC is very extensible and does not require to adhere to the Controller, View, and Model folder structure. You can place the controllers anywhere you would like, however if they are located in another assembly you will need to implement your own controller factory that knows how to locate them. Here is an example for locating your controllers with Windsor.
Your models/view models can be where ever you want. You simply need to reference their namespace in the web.config so views know where to look. (At least I know this is true with the Spark view engine.)
You put your views in any web project. My usual strategy is to create a plain web (non-mvc) project that contains the views folder. (This could even be a legacy web app!) Then all my controllers go in a separate class library. My view models and services go in another.
As far as structuring folders, I usually center my hierarchy around domain concepts. I'd have a folder in each project for Users, Products, Orders, etc. I never have a Models or Controllers folder anywhere.
You need to use portable areas see http://www.lostechies.com/blogs/hex/archive/2009/11/02/asp-net-mvc-portable-areas-part-2.aspx