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.
Related
I keep reading that the biggest layer in the MVC pattern should be the model. I've also heard that we should avoid putting logic on the controller layer. However, as my ASP.Net MVC 5 application is getting larger, I see that I'm getting heavy views, heavy controllers, and... extremely tiny models (they're not more than references to my SQL tables).
Yes, I admit, I could never manage to put any logic on my model.
I like the MVC pattern, and my website is working good, but I keep on thinking that I'm surely not doing things right...
Can you show me some useful links about how to write MVC code properly? Rick Anderson's (Microsoft) MVC 5 tutorial is fine, but once again, his models are indeed very tiny...
In my applications I put as much logic as possible in the domain models. On top of that there is an application layer which interacts with the database and domain models to perform application specific operations. The controller actions have as little code as possible and just call methods in the application layer.
In addition I usually have a view model for each view. Any logic that you have making your views "heavy" would go there.
One of the main reasons I try to put as much logic as possible in the domain models is to make unit testing easier. Logic in the application layer usually involves the database, which you will need to mock in order to test. Moving logic to the domain models makes testing easier and makes you code more reusable.
This is a pretty complex issue. I have an in depth blog post on the question if you're interested.
This answer is also pretty close to what I would suggest.
You're missing a service/business layer which should be injected in your controllers though "Dependency Injection". These services do all the heavy lifting.
Having Models without any methods or operations in them is a good thing. You're only storing this info anyway. They basically just get; set; data.
Use extra layer between models and controllers (for example repositories as data access layer).
I strongly recommend using ViewModels-they make code much more organized.
You should Create Some Classes that purely doing business logic and emit ViewModels for MVC view. Controller should respond to actions and the action method delegate the responsibility of getting the model to this business classes.
After some research on this issue, and taking into account some of these answers and comments, I realized that a medium sized MVC project can't rely exclusively on the 3 layered model. As the controller actions become bigger, the developer starts feeling the need of creating a 4th layer: the service layer. Like Gunnar Peipman correctly suggests in the following blog post, "Controller communicates with service layer and gets information about how access code claiming succeeded": http://weblogs.asp.net/gunnarpeipman/archive/2011/06/20/asp-net-mvc-moving-code-from-controller-action-to-service-layer.aspx
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.
I am facing a design issue with an mvc 3 app. I have a viewmodel ProductCreateModel that has a list of Categories.
Now I am setting the Categories list in the controller, but I am thinking if it is a good idea to indect the datasource in ProductCreateModel constructor.
Do you think that view models should be fat models that also know to read dependent data from the data source? ... or this is a controller thing?
I prefer slim viewmodels that do not know a thing about data layer. They are easier to manage (in my experience).
I think view models should be light models, and the only way for them to read related data, should be properties on "parent" object, the model they actually wrap.
Most of the time my view models are just classes with properties, all logic are in the controller or in a service class (if we're talking a lot of logic that would otherwise be put in the controller). All this is in the name of easier testing.
When I learned MVC I was taught that the "rule of thumb" is Skinny Controllers, Fat Models, Dumb Views. A mistake that many MVC developers make is Fat Controllers (too much logic), Skinny Models (basically POCO classes to hold data), and Smart Views (a bunch of Razor Syntax with If this, Else that, etc.)
Over the years I've stuck to the Skinny Controllers, Fat Models, Dumb views approach, and it has worked well for me. Now, take into consideration that this is related to Models and not ViewModels. Usually your Models should be in an entirely different layer (i.e. proj or folder). ViewModels, on the other hand, should be fairly simple. This makes them easier to test, and more reusable. If you are finding that you need some sort of service, repo, or other dependency to build up your ViewModels, then you should probably abstract that logic out into some sort of Composer Class. In the past I've used a ViewModelManager which implements IViewModelManager, to compose my ViewModels if need be. This way you can inject IViewModelManager into your controller, and use it to build your ViewModels. Then, in your ViewModelManager implementation, you can inject your other dependencies, like repos, services, etc. to actually construct your ViewModel.
This approach definitely requires more code, and many more classes, but it will give you a good level of granularity, and separation, plus support the DRY principle along with Single Responsibility.
Happy Coding!
As a general rule, I don't think you want to do that.
As an exception to that rule, I've started using a little bit of Service Locator in my Editor Templates when creating drop downs. I've gone through multiple ways of populating drop downs (generally, some form of adding a collection to either the view model or into view data). I saw a video where SL was used in the Editor Template to get the data and then convert to a Select List. My initial reaction was "ugh, really?", but, the more I thought about it, it made sense.
I'm starting to learn ASP.NET MVC. I understand the concept of controllers, models, and views. Yet now that I'm starting to design my first site I'm a little lost as to what controllers I should be creating. Do most model objects have a corresponding controller? Or are there other considerations I should be making when grouping action methods into seperate controllers?
Controllers logically separate small areas of functionality (Not to be confused with Areas in MVC which separate larger functional sections).
Do you have User Account Management for stuff like CreateAccount, ChangePassword? That's a UserAccountController.
Do you have functionality that allows people to create, view, delete Forum Postings? That's your ForumController.
Do you have functionality that allows people to manage their Preferences? That's your PreferencesController.
It's not so much 1 Controller per Model, it's 1 Controller per logical section in your app (which often indeed is one Model class). Some non-trivial MVC Sites work fine with only one controller, while my last project had eight of them.
In my limited experience with MVC so far, most of my controllers correspond to the model objects. I would also feel that you would create controllers for specific functionality within your site, like uploading files, etc.
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