I\m using WebAPI in ASP.net MVC 4.5, and I was wondering what is the best practice when dealing the db entities, should I create another Model (you can call it API model or Service model) that deals with the API, pretty much the same way you create a View model to deal with the razor view, or just communicate directly with the db using the EF entities.
When it's a public API, I think its better to create extra Web API entities (Models in MVC). You can write a method to map the db entities to Web API entities. When you create extra entities your sure the public side of your API doesn't change when you change database entities.
Related
Right now I have a few layers to my project: Core <> Repository <> API... and I'll be building a "client" MVC web project layer. My question is - where do viewModels belong in this architecture?
Should the controller methods of the Web Project call the API (multiple times - getTheseObjects, getThoseObjects) to get data, and then build the viewModel? Or should the API support calls to construct the viewModel so that only one API call (getAllObjectsForThisPage) needs to be made per page for the application?
Your view models will belong in your client MVC app. They will be specific to the views in that individual client application, and usually will get populated by domain objects.
This is how it can work: the controller mediates the https requests thus calls a API endpoint and receives some data or domain objects, which in turn you use to populate your view models.
Take a look at automapper if you are returning domain objects from your api, it really helps with mapping domain object to view models.
You can place ViewModels into your MVC application, but you could create something that is called DTO (Data Transformation Object) and return that from Web API to your client. In essence it will be a class with only the necessary information that you pass to the client. If you want to call that ViewModel you might as well go ahead and call it like that. My suggestion would be to issue one call and to return all the necessary information. One call one trip.
My practice usually is to separate ViewModel from MVC and store it in some other project. The service layer would prepare a ViewModel and return it to MVC. The reason for this is that once I had a requirement to build WPF application after MVC was completed. It was quite a pain moving things around and retesting everything to make sure that it still works fine.
I have a database. I have a Wcf Service project which is connected to the database and has a data model (.edmx file).
Now I need to add an Asp.Net MVC application.
The tutorials I'm reading say that I should only add the connectionString. But, does that mean that I don't need model classes? Or should I create model classes? Also, the classes in the .edmx file don't extend from DbContext the class.
For example, I have a table named Something in my database which doesn't extend from DbContext.
Do I add a model named SomethingTemplate with all the properties from Something and make it extend from DbContext?
In a properly designed ASP.NET MVC application the data access layer is abstracted. This means that no matter whether you are using plain ADO.NET, EF, NHibernate or even remote WCF service calls it doesn't really matter.
In the case of WCF if you want to use EF, you will define your data contexts and entities inside this project. The connection string will also be inside the WCF project.
Then in your ASP.NET MVC application you will simply add a service reference to this WCF service which will create a client side proxy allowing you to invoke its methods. It will also import the entities but from the ASP.NET MVC perspective they will be POCOs.
How would I go about abstracting the membership information in MVC3 c#
Currently the membership data is kept on a localhost SQL server and is linked to MVC via the Entity Framework.
As I want to perform some extensions, I need to abstract it, creating an interface and class for each entity in the SQL database?
Where would I start? Are there any examples available? I can only find ones that are out of date or irrelevant
I think you can rearrange your application, introducing a service layer separated from your presentation layer. The object model (domain model) that you define in the presentation layer for User and other entities should be distinct from the EF data model, so you need only that some sevices ( for example you can implement these as Web Services) read the data using EF and populate your domain model of the presentataion layer.
This approach allows your application to be more flexible to future changes or extensions.
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.