I'm doing a project with ASP.NET MVC3 and Linq to Entity . I have separated my data access layer through a different project and of course its not highly coupled with Model.
I have seen the scaffolding ( auto code generation for controller and corresponding views) feature which depends on Model.
Is there any tools or specific procedure through which I will be able to generate views for a specific controller like scaffolding do for ASP.NET MVC without involving model highly like MVC do ?
Thanks
You can go through the MVC Scaffolding articles. Basically what you have to do is edit the default templates and power shell scripts.
The model that you are talking about here doesn't have to be a Database generated class. It can be anything, so what I would do is create a ViewModel (class) that will represent that view you want to display and use the Scaffolding functionality on that ViewModel.
You can then use something like an Automapper to bind your models to the view models
Related
I'm currently using the ADO.NET DbContext Generator to generate domain objects from an entity model. Are there any tools that can generate a view model for each of the domain objects? Adding data annotations, like [Required], [DisplayName] and [DataType], to the view model properties would be nice too.
I'll be adding to these generated view models to build more complex view models but at least the most tedious work is automated.
ASP.NET MVC 4 RC
Thanks!
No, there are no such tools. It is up to you to define your view models. A tool cannot possibly know how your views look like and what information they contain. Remember that a view model could be the projection of multiple domain models. A tool can generate models from an existing database schema, but there's no such thing about view models. Their design is left to the ingenuousness of the developer and IMHO that's better.
Are there any tutorials/examples on how to create an asp.net mvc app without the model being managed by a database (through linq2sql or entity framework).
I've to create a frontend for a server which has a json based api. I would like to use mvc 3 or 2 and have most of the features of mvc still in place (like data annotation and validation).
Any tutorials or examples on how to do this? I tried to search them but all examples i find are based on entity framework or linq.
I agree that most of the examples/tutorials out there are using entity framework. This being said the process would be similar:
Create your model classes.
Create a repository working with those model classes. This repository should implement an interface which contains all the operations you need with those models like GetUser, SaveUser, etc... In the implementation you connect to the remote JSON API server to fetch data.
You create a controller which takes the repository interface in the constructor. Setup a custom controller factory so that a DI framework could provide instances of your controllers.
Define views and view model classes.
Controller actions talk to the repository via the provided interface to fetch models, maps those models to view models and returns them to the corresponding view to be shown.
Useful tools:
MvcContrib (many useful helpers)
AutoMapper (for mapping between models and view models)
FluentValidation.NET (for validating models)
MVC 3 has extra support for JSON which you might want to look into.
Or use the futures with MVC 2.
I'm new to MVC and even though there is a lot (and I do mean a lot) of information out there that is very useful - it's proofing very difficult to get a clear understanding on how to achieve my exact requirements with MVC 2.0.
I would like to set up a solution as follows:
Provide a web UI using an MVC 2.0 project.
Use Linq to SQL classes project for data persistence.
I have a two separate code modules that will need to access the above Linq to SQL model - so I won't be able to include my Linq to SQL model directly in the MVC project itself.
Also I have a Business Logic layer in front of my Linq to SQL project.
My questions are:
How do I set up the Model part of my MVC application to point to my Linq to SQL project via my BLL?
How do I perform web app validation? Can I use MVC 2.0 Model Validation? If not what are the alternatives?
Finally (and slightly aside) - What is the ViewModel and how does this differ from the Model?
So many questions. But this is an exciting new technology and data access issues aside, everything else I've got to grips with very quickly and I think MVC 2.0 is fantastic.
Thanks for any pointers you can provide.
How do I set up the Model part of my
MVC application to point to my Linq to
SQL project via my BLL?
Typically you'd use a repository pattern for this. Your controller has a reference to your repository - the repository returns your domain objects from your database. The MVC app has no knowledge LINQ to SQL exists.
How do I perform web app validation?
Can I use MVC 2.0 Model Validation? If
not what are the alternatives?
Put view models in your MVC project. These view models may closely align with your domain models but their concern is to be the presentation model. Put your data annotations for validation on these view models - the MVC framework will automatically ensure validation occurs on these view models decorated with data annotations. It's pluggable so you could use alternatives - but with MVC 2, it's baked in fairly well and this includes client side validation.
Finally (and slightly aside) - What is
the ViewModel and how does this differ
from the Model?
I partially answered this one above. the shape of your domain models may not be the shape you need to display your views - view models are great to bridge this gap. Additionally, even if the shape does match exactly - view models are still a good idea so that you can put UI validation code there and other presentation meta-data on them (since you do not want anything related to presentation logic on your domain model).
Here's link for view model patterns.
Hope this helps.
You can add a reference to the objects exposed from your BLL assembly and use them as your Models.
When you want to add validation to classes that are generated use buddy classes.
A ViewModel is a custom-shaped aggregate of Model data. There is exactly one per View, as the ViewModel's purpose is to surface exactly the data needed by a particular View in a convenient and concise way.
An example might be a View that contains both Order and OrderDetail information. A ViewModel can hold internal references to the repositories and business objects for each type. Properties of the ViewModel merge together the data from these objects.
ViewModels will be useful in your case also because you want your Models to be in a separate assembly. You can apply the DataAnnotations to ViewModel properties for validation. You would make the "raw" business object models internal properties of your ViewModels, and expose public methods to retrieve and persist data.
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.
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