Are there any best practices that cover the places that ASP.NET MVC models should be defined?
A new ASP.NET MVC project has a nice neat Models folder for them to go in, but in a production environment they can come from other places:
Third party class libraries
WCF services
Is it acceptable for a strongly-typed view to use a class defined in such a location?
In just about every project I have worked on the models of ASP.NET MVC are more View Models than models in the traditional sense of the word. I have yet to have a project where I can use the same Model that I use in my data access for my View Model. There is just too much other information that needs to be displayed on most pages. So for that reason I will either store my models in the models folder or store them in a separate library with all of my other MVC specific classes.
I don't know what you exactly mean by putting models in WCF services. If you mean using WCF services that expose the model object you need, that would work.
Regarding separate class libraries to hold your models, views and controllers, I think that's a pretty common approach and works pretty well. In fact, I believe this is really a requirement when the size and complexity of your application grows. It's a kind of physical separation of the distinct logical components in an MVC app.
One issue that I've found is that, unless the model is defined in the web project, VisualStudio seems unable to find it when using a strongly-typed view specified in markup. My models are usually defined in a separate project and I've found that to use strongly-typed views, I need to create a codebehind so that I have a class that derives from a strongly-typed ViewPage. Then I change the markup and associate it with this class.
You need to import the namespace to the view page. This does not require a codebehind page.
Use the directive
<%# import namespace='your.namespace.here' %>
immediately after the <# Page..... directive
Related
I've seen it all over SO, blogs, and books, where the authors tell you add ViewModels specific to your View in your Model projects as wrappers for your underlying model objects. The idea is to make it very simple and targeted when you go to do model binding to the View. Here is a good example: Rendering and Binding Drop Down Lists using ASP.NET MVC 2 EditorFor
However, it irks me a little that there are references now to System.Web.Mvc in my model, which otherwise could have been used for multiple outlets (maybe WCF API, Silverlight, etc), but now I have specific references to MVC dll's that will be required to get my model project to build.
My question is: does this violate MVC patterns when we start adding IEnumerable<SelectListItem> to our model classes? And is there a viable alternative layer to move this to and how, ie Controller?
Any thoughts or comments appreciated.
I personally only create the select list on the fly in the view, from a more re-usable IEnumerable list in my model, which means my model doesn't have anything related to SelectLists, SelectListItems or anything MVC specific.
Example as promised - create the SelectList in the view, using all the normal view engine bits...
<%= Html.ListBox("SelectedStuff",
new SelectList(Model.SomeOptions, "id", "name", Model.SelectedStuff)) %>
does this violate MVC patterns when we
start adding
IEnumerable to our
model classes?
Not really BUT if your trying to use a Domain Driven Design or separation of concerns between you business layer and MVC/presentation layer than it is a violation.
Models are your entities, your
domain, your business layer objects.
ViewModels are your screens, form
postings, display data buckets.
Models map to ViewModels which can contain MVC dependent items. Think if it this way, ViewModels are directly for MVC. Models could be for a service, winform, WPF or any programmatic presentation of the business sytem system.
No, ViewModels are meant to be consumed by the View and should be located in your web project. However, your actual Model should have no reference to MVC or your web project. Think of your ViewModel as bridging that web gap from your Model to your View.
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
As discussed throughout the various MVC questions and blogposts, we know that the ASP.NET MVC project layout is heavy on convention.
I blindly made a sub-directory in the Controllers folder.
This doesn't feel right.
alt text http://www.imagechicken.com/uploads/1252003002097179400.png
Question: What's the common accepted convention on which directory to store your ViewModels? What are your suggestions or what is the established convention?
I use a "Models" folder alongside Controllers and Views. The same one which is empty in your project (I don't use Areas).
The "M" in "MVC" model goes in a separate assembly. The only models in the web assembly are presentation/edit models.
Inside the Models folder, there are subfolders by namespace as usual. So I have:
Vertex.Data (Assembly with repositories, etc.)
Vertex.Web
Controllers
BarController
FooController
Models
Bar
BarListItem
Foo
FooDetail
FooListItem
Views
Bar
Foo
Shared
...etc.
I typically create a model for every view. Even if it is just an exact map of some other object in my project that I could be using. This way my view and it's required model is decoupled from the rest of the application. It also makes adding data to the view in the future very easy by just extending your view's model.
It takes a little more work up front and sometimes seems like your duplicating objects but I just prefer the seperation.
I store all my view models in the models directory created in an MVC project. Those 'models' map one to one to my views. I use subfolders within the Models folder if the view models become more than just basic data holders. The subfolders would contain all the bits and pieces required to represent that view.
I think the idea is that (View)Models should go in the Models directory (which is empty when you create a new ASP.NET MVC project).
Personally, it makes more sense for me to arrange namespaces around features instead of mechanics, but while this is of no consequence with regards to Models, it would have some implications when it comes to Controllers and Views.
In my first ASP.NET MVC applications, the model was a simple O/R mapping between a table and the classes, managed by the Entity Framework.
Now I would like to add some meat to this skeleton, and introduce business methods for the generated classes. What is the recommended approch to this in ASP.NET MVC (with Entity Framework)? My favorite would be solution which also can be used in a service layer, with no ASP.NET MVC references, so that the same domain logic also could be reused in a desktop client.
Technically, I think it should be possible to extend the generated classes in a way which preserves the additional business logic even if the O/R classes need to be refreshed. (This is more a question related to the Entity Framework however.)
Edit: Many thanks for the contributions, and the information about the next version of Entity Framework (4.0). Building two sets of classes, one auto-generated to represent the data in the persistency layer and one for the actual business logic sounds interesting.
Within MVC.Net, the model is the least clearly defined part. In my opinion, it's basically the rest of your application (i.e. anything not related to the View or the Controller). The O/R Mapping part of your application should probably be outside of the "Model" also, as this is more of a data layer. The Model, should really deal in business objects and create views of your data to pass to the View.
There are lots of differing opinions on this, but I think it's best not to think of MVC.Net as traditional MVC Architecture.
If you are using EF v1.0 right now, the Entity Framework is very intrusive into your application, which means that you cannot create POCO very easily. The way you can extend your model is by using the partial class. So when you refresh your model, the partial class you did will still be valid. The Entity Framework team realizes this is a problem , and have improved this in next version (EF V4.0).
NHibernate is much more friendly and allow you easily extend your business logic.
I really think this blog post by Jeremy D. Miller is very good at pointing out the problem.
Abstract your Business Layer out into another project, then pass an instance of it onto your mvc controller using something like structure map. You can then call this Business Layer from your controller to retrieve your business entities (Model) and pass them on to the UI. This will allow you to resuse your Business Layer in your desktop application.
Not only meat but also some clothes and a style could be added to this project to make it seem chic. It depends on the time you have for the project. If you have time, I could suggest you to get a look to TDD and the frameworks that could be used with TDD such as Castle, NUnit, Moq etc.
As you mentioned a service layer is a must for any project but with these kinds of frameworks you could design your architecture more robust.
I have a fairly complicated ViewModel associated with a product listing form, which has a lot of custom default values depending on the currently logged in user. I'm finding that populating it in my controller is quite a chore. So I'm thinking of creating a factory class for it, but I'm wondering where in the project structure it would be a best fit. In the Controllers folder?
I'd move it out into a separate Common or Core folder, or Common or Core project for that matter. If you can decouple the logic that's not specific to MVC, you'll probably be better off in the long run.