I have a mvc web application which consumes web api service. If I want send complex form data represented in MyModel from mvc to the webservice, should webservice have MyModel as part of the project.
This way I would have MyModel on both projects, mvc and web service. Is this right approach?
In my opinion they should have different models and do the necessary mapping to avoid interdependent. In this case both projects ended up intact. This approach is called Data transfer object (DTO).
Benefits
You only care what you need thru mapping
No be big effect if model in different project change
Obviously you will not be tied up on other model outside of your domain
Disadvantages
You will end up many models
Expensive process
You will appreciate DTO specially if you're working in different teams working on different parts ex. One team woking on views and different team for backend. Also if your consuming external APIs. But you can apply this approach in your case.
Related
I've two projects in the same solution, and I'm wondering what is the ideal way to share the database between AMS and the Asp.Net website. Also, as they both use Entity Framework of some sort, I found it tricky to keep the models synchronized between projects.
Idea 1: simply let them use the same connection string; but what if I used code-first migration in one project, and the other can't update because its migration history is behind?
Idea 2: doesn't let the Asp.Net website touch the database; let it communicate via HTTP requests to the AMS instead; but would that add additional network overhead for the communication?
Idea 3: create a separate project to contain all the entity framework classes and DbContext, and let both projects refer to it. But as the AMS project requires EntityData classes instead of POCO, it causes unimaginable trouble for me to reuse the model classes in other project. I just can't let the website start once I have all the mobile service nuget packages installed.
Any thoughts?
just a few thoughts on your question,
Idea 1: Will cause you trouble as you suggest when you preform EF migrations going forward. The models in each project may end up being different, EF won't like this. Best to stay away from this solution.
Idea 3: is what I tend to use in projects that aren't too heavy on usage and don't have a large codebase with infrequent updates. Create a single Data Layer project which contains all the EF context and migrations, then reference this data layer in multiple domain layers or front-end layers. This works pretty well and can keep things simple for you. Mobile Services exposes database entities via RESTful APIs so there shouldn't be too much trouble there. The Website should use DTOs and view models to move data around between layers. The only problem I have with this solution is when you update the EF models in one project, you will also have to update and publish the second project as EF models would have changed. To get around this I have automated the build and publish process, just to make the process a little easier to manage. Do consider the life of your solution, you may end up in a case where you're project data models diverge and you end up having two data models within one database. Splitting theses out later into two databases can be very painful when you have to bring the data with you.
Idea 2: In more complex cases, where I'm working on large project and continuously updating the code-base and the project is going to last into the foreseeable future, it's best to separate both services using an interface (which won't change too often) and remove the direct dependence on the shared database. You could as you suggest have the data stored in AMS and then just access it via REST requests from the website. Traffic can grow and may be a problem later depending on the demand of your site and mobile services which may slow down your response times to your website. Though initially, my concern would be in response time to your site from the many hops from the site to the mobile services interface to db then back again. Though you should be able to mitigate the effects with this with a cache for the read data, not the write data though.
What I would do in your situation, to make things easier on the deployment is to combine both the website and mobile services into one solution and host the combined website and API together say on an Azure Website alone, sharing the one data layer containing EF. Thus do not use Mobile Services if you do not have to, depending on requirements of course. ASP.NET can nicely support both under the one roof. This is a little outside of the scope of your question but something that might be useful to consider for your immediate problem.
Please bear with me as I am new to MVC and WCF and may be asking the wrong question.
I am trying to write a WCF service and an MVC web application over an existing project that contains entity, data and business layers. The MVC and WCF components would then replace an older web service and WebForms application which worked very diferently and did not use modern practices.
I see the need to generate DTO objects against all Entity objects and was wondering how we can generate them. Through reflection, digging into the DbContext or some other method.
Furthermore, I also want to generate repository partial classes minimizing the need to maintain hand-written code for a large data model.
How do large development teams do this?
I'm new to using the ASP.net MVC framework (and C# too). I have more experience using JSP + JSTL MVC framework. I want to know how to run custom queries if I need to do more complex sql.
In the JSP framework, I'm used to creating DAOs to query sql tables which doesn't seem to be the case in ASP.net. For ASP.net, I noticed that we use LINQ to do the querying over a DBSet object from a model.
My Questions:
Where do I write the custom query code? In the model?
How do I write it? Is it through some sort of db.execute statements?
Are there any configuration changes I need to make?
Examples and other resources would be nice.
I tried looking through the asp.net MVC tutorials on asp.net, but I couldn't find anything.
How you execute SQL queries depends entirely on what data access framework you are using. You can write plain SQL with ADO.NET and execute queries in a manner much like that you would expect.
In answer to the second part of your question, this should be done in a data access layer and be completely unrelated to your ASP.NET MVC application itself. Any necessary logic for instantiating and communicating with classes in that abstracted layer should reside in your controller (and, ideally, be loosely coupled from your application via the use of interfaces and/or service layers).
In this sense, yes, it belongs in the model. However, bear in mind that, conceptually, the 'M' in ASP.NET MVC is the domain model (i.e. the aforementioned data access layer), not the view model. The view model is just an independent wrapper that is designed to store relevant data for a given view and should - in most cases - be completely devoid of logic whatsoever.
In the JSP framework, I'm used to creating DAOs to query sql tables
which doesn't seem to be the case in ASP.net.
It is very much the same, you should have a separate DAL project with your DAO objects and reference those from your Business Layer (another separate project). The ASP.NET MVC project itself will add a reference to the Business Layer project which in turn will add a reference to the DAL. That way, you can keep a 3-tier architecture:
UI (ASP.NET MVC project)
|
|
Business Layer (POCO objects (= to POJO), validation, biz logic) - separate project(s), depending on whether you put your POCO objects in the same project or not.
|
|
Data Access Layer (You can use ADO.NET, EF (LINQ), etc.)
An ASP.NET MVC app usually is composed of 3 folders: Models, Views, Controllers but everything that's typically placed in the Models folder is really your Business Objects so I tend to get rid of that folder completely and I am left with just the Views and the Controllers folders. The views are just the html markup, pretty much. The Controllers classes simply call the methods from the business layer and passes the results to the views. So for example, a UserController class will look something like this:
public class UserController : Controller
{
public ActionResult Index()
{
var allUsers = UserBusLayer.User.GetAll();
return View(allUsers);
}
}
Currently I'm working on a project which is using WCF directly to interact with Service functionality instead of WCF RIA. The problem is I create Model for each Entity (in service) inside silverlight client application for validation, That's OK. But I should populate Server Entities with Client Models each time I want to Insert or Update an Entity in database. Is there any way to prevent these extra works?
A typical first version of an MVVM (Silverlight) Client and (WCF) Service has a lot of duplicate types, logic and mapping between types.
This is one of the reasons why WCF RIA Services has been created.
In a first version of an MVVM application the Model and ViewModel will be very similar. When new requirements appear and the Views get more and more functionality added these will diverge and the Model will become very different from the ViewModel.
The Model will be determined by the the service and the ViewModel by the Views. This will cause the mapping to be less and less trivial.
I have used T4 templates to generate ViewModels based on XML definitions. This prevented the need to write the boring, repetitive mapping code.
EDIT
See the MVMMapper project on Codeplex for the generation of ViewModels using T4
FYI, I'm working on my first MVC web application using MVC 3 and Razor with C#, and .NET3.5/4.0, and I'm looking for the "best pratice" approach for using existing web services in an MVC 3 application. From what I have figured out so far it looks like all I need to do is the following. Include a reference to the existing web service in the MVC project, create a Model for the data I desire to use in the application, create a Controller that makes the web service call that then fills an object created from the Model (reading about AutoMapper to see how this helps in that process), and then create a View to display the data that was translated into the MVC view model.
The part that I'm having questions about is what is the best way to retrieve and create/update the data from the web service. Maybe I'm over complicating this but it seems like I'm missing something.
Do I need to create a "Domain Model" that maps to the data retrieved from the web service and then create "View Models" that map to the domain model, and then use the View Models within the MVC 3 application?
Basically I'm looking for input on how best to use existing web services as my data access layer.
On your data access layer you would open the connection, get the raw data and then close it. Identically to how you would get data from your database. You would then convert this raw data to your business layer (domain model) via a data adapter. Then any top level applications, such as your MVC3 website, will convert this domain model into an approriate view model, along with any other data for rendering, again through a data adapter.
The main argument for doing it this way is that the service is now accessible to any top tier application that requires it. It is also makes logical sense to put any sort of data retrieval methods in your data access layer, since that's logically what the data access layer is designed to do.
There is always the temptation to simply access the service from your controller, but separation of concerns might suggest this is a bad way to structure your code. You should encapsulate the service as a domain/business layer service for your applications.
So in short, you don't need to, but best practice suggests you should. It can feel tedious sometimes when there is little or no conversion between layers, but it often helps to stay consistent.
To obey the MVC pattern and its separation of concerns, calling the database must be in the model. And if this web services calls the database somehow, it should be at the Model level.
let the UI talk to the model directly, in case later u needed a webservice to integrate with another system you can create a service which calls that model
And you may want to cache it if its read-only