I'm building a web application using ASP.NET MVC6 that needs to be accessible via a web browser (via Views), as well as from mobile applications via Web API. The thing is that I would like to avoid duplicating business logic in controllers.
I know that MVC6 controllers return an IActionResult. When used as an MVC controller, the IActionResult might be a view. When used as a Web API controller, the IActionResult might be data (such as a list of products). The same controller might have actions (two different actions) that return both views and data.
But my requirement is to have one single method which can be used to render views when called in normal way in form of website and return data when called as Web API method.
As you’re already aware, MVC Controllers and Web API Controllers are now exactly the same. They’ve been unified as of MVC 6.0.
When you say you’d like to avoid duplicate business logic in the Controllers, may I ask why is it like that in the first place?
Do you have/shouldn’t you have some sort of Class Library project acting as your Business Layer in which you store all your relevant business rules?
For example:
Contoso.Web ( MVC 6.0 application)
Contoso.Service (Class Library holding your business rules)
Contoso.Data (Class Library holding your DataContext and Entity
Framework stuff...)
Contoso.Core or Contoso.Domain (Class Library holding your domain
classes/POCOs)
In addition, you want the ability for your application to be viewed from within classic browser as much as from mobile devices. Have you considered building a SPA (Single Page Application) which gets you best of both worlds?
The SPA approach, will allow you to create Views and using a client side framework (ex: Angular) will allow you to invoke your WebAPI which in turn would invoke your Contoso.Service layer.
Unless, of course, your mobile app is a native one that only needs to invoke your WebAPI
If there is a way for an IActionResult to either return a View or some Data, the concern I have is that this IActionResult may start growing and having some discoverable logic in them which may be hard to maintain/debug in the long run.
You also increase the likelihood of regression when you modify its behavior since you’ll need to test both the Views and the mobile app.
With little I know about your project, I’d take a look at SPA approach to see if it fits your need(s).
Related
I've explored the ASP.net web API framework and MVC 4. I understand the point of using web API that only return data then in client side we use javascript, ajax to handle all actions via HTTP verbs. On the other hand, MVC controller can return data and view we can handle event via [HttpPost] in controller.
I saw some people they make 2 projects in a solution: one is Web API in MVC 4 and the other is MVC 4 Internet Application. Is it a good idea? I didnt see the relation between two kind of projects. Can anyone explain me the how two project can communicate with each other, and what is the advantage and disadvantage of that way?
Note: in this solution he/she still uses Httppost to handle event and use MVC controller return view with Model binding.
Well I guess this is going to be a pragmatic conversation...
For starters, it seems like the Asp.net WebApi and Asp.net MVC are going to be aligned in Asp.Net V-Next, so there is going to be One base controller class that will return what ever datatype you wish (ActionResult, Json etc).
And from the recent years experience I think the trend is to have a WebApi that exposes data and a portal(client) that is just a JS web application with no C# code that just calls the Api from the browser and does what it needs to do.
So that way we basically save one hup to the server(the MVC server) and we can directly call the API from the browser.
However some people would still argue about load balancing, scaling, caching etc that you could have if you keep the MVC tier there but still all those things could be done in the WebApi and JS application too...
So long story short, I think if you want to move with the trend I think you should go with a RESTful API and have your client to call it from the browser directly with JavaScript...
Cenario
Website: ASP.Net MVC 5 managing models, controllers and views.
Api: RESTful Web api managing models, controllers and returning JSON
The problem: Code duplication in BL. We are always redoing the same logic in both places.
The approach I have in mind:
Take the BL out of the Website MVC and keep it only in Web Api in a separated VS solution
The Website now is a consumer of Web Api
About the content negotiation, I think in two options:
Web Api "knows" which format to return (ViewResult, JSON or XML) and serialize/deserialize in BL depending of who is requesting (website, mobile apps, etc.). The advantage I see is to keep taking
advantage of strongly typed model to render a view in Website
Web Api always return JSON and the consumer app handle result in client
Questions:
Is this approach a good practise?
Which is better: Web Api always returning JSON or a smart Web Api who "knows" which format to return?
Like #David said, you don't really need to consume web services in your MVC controllers. You could just design it in such a way that your MVC and API layers are just another "view" to your Business layer. So, in case you are thinking in a terms of your visual studio solution, your might have a Data layer project, a Business layer project and 2 front end projects MVC and API.
I'm working on building an application that's based on SOA. I have bunch of business services that I should make them available as components to another applications (so I'll use web services -SOAP-).
The application presentation layer is MVC.
1- Model: Contains DataBase methods (ORM is used).
2- Controller: Contains calls to the model methods as well as methods to handle simple view actions.
3- View: Contains rendering content only.
So, can you give me a simple scenario how can I combine web service with my MVC application, my suggestion is to separate the model as web services, is that right?
I'd tackle it this way: (YMMV)
Build a data tier assembly housing all your data access. Call it the DAL. It will contain all data access methods. This will enable re-use, but also allow for methods used by one application below. This is where your EF model can live.
Build 2 web projects: MVC and web services. Each will implement business logic to satisfy their respective requirements. They'd reference and call into the DAL as needed for data access. As you noted, they're both presentation-tier services. One has a user interface, the other is a communication endpoint for remote web service consumers.
Deploy both onto an application server as needed. Suggest creating 2 applications/sites in IIS - (i.e. "Web" and "WebServices"). This separation of applications ensures that one can be changed/downtimed/versioned without effecting the other.
The MVC project/app will still have its Models, Views and Controllers as per normal. The biggest change here is that the Models would be used only for ViewModels as needed. It would contain any business logic to satisfy the UI requirements. Its controller methods would call the appropriate DAL public methods as needed.
The web services project/app would be able to be changed independently as needed, while the data access would remain.
1) Place all your service operations behind an interface.
2) Consider using an Inversion of Control container to utilize dependency injection in your application. This allows you to mock your dependencies and unit test your controller logic more easily. Some examples are Windsor, Ninject, StructureMap.
3) Consider using strongly type view models for your views, instead of the objects that your ORM works with. You'll want to set up some mapping classes to help manage this, but a lot of the pain can be taken away by using something like AutoMapper.
Here's some good links on the subject:
How we do MVC – View models
ASP.NET MVC View Model Patterns
Never use web services for the sake of using web services: You should first have a problem that needs solving, and see that web services are the best solution to your problem. So depending on your need, web services can be used in a variety of different ways.
For example, since you say MVC is your presentation layer, you may want to insert web services as a layer between the Model and the Controller. Rather than invoking your model (data layer) directly, the Controller invokes your web services and provides a web-based front-end to the services that would otherwise be available via your SOAP API.
Another option is to make both your MVC front-end and the SOAP services access a common business/data logic layer, each providing their own "API" for the same back-end.
But again I emphasize: web services should not be used as solution in search of a problem. If it's not obvious to you where the web services should fit into your architecture, you are very likely better off without them.
can any one explain the difference between the mvc and web application in asp.net.
in mvc we can find controllers folder. cant we able to find controllers folder in web application..! please vanish my confusion.
MVC uses controllers to orchestrate the models and views to provide user interfaces to the user.
Web forms doesn't use controllers to achieve this, it uses code behind with events.
MVC is built around the notion of separation of concerns - each thing is responsible for its own bit, and shouldn't be concerned with what other bits are doing. Webforms has them a bit more mushed together, where code sits associated 1:1 with the webform (in the code behind), often leading to business logic creeping into the UI.
WebForms uses a powerful eventing system to help abstract away some of the complexities of HTTP, such as its stateless nature. MVC doesn't do this, which requires the developer to work within the confines of a pure HTTP environment. The eventing system in WebForms lets you quickly wire up events in a familiar way if you've come from a VB6/WinForms background (which the target audience had when ASP.NET was first released).
Have a look at http://www.asp.net/mvc which has a lot of great tutorials on getting started with MVC.
An ASP.NET MVC application is an application which depends upon the ASP.NET MVC Framework. MVC stands for Model, View Controller, the three components which define an application created using the MVC pattern.
The MVC pattern aims to seperate an applications logic, data and presentation into distinct, somewhat independent components.
Model
Models are a representation of an application's data. For example a shopping application might have a Cart model to represent the state of a user's shopping cart.
View
A view is a visual representation of the data contained in the model. A view class should knoow the specifics of how the model(s) it uses should be presented.
Controller
The Controller's job is to handle user input and update the state of the Model to reflect the changes that were made as a result of user action. For example imagine the user is viewing a Contact Us page and clicks the Submit button. The controller would respond to the button click by updating the model with values from the form fields and then save the model, causing it to be validated and then written to the database.
This is a very shallow and incomplete explaination of the MVC pattern you should head over to the ASP.NET MVC homepage to get a more complete view of the MVC pattern and the ASP.NET MVC framework.
An ASP.NET Web Application uses a separate framework known as Web Forms. Because Web Forms does not use the conventions defined in the MVC pattern, the Web Application template does not create a similar folder structure .
The use of either framework is not mutually exclusive, the two represent differing approaches to the same problem. With respect to which is most efficient for data access I would refere you to Michael Shimmins' excellent comment
I have an existing Asp.Net MVC Website and I would also like to provide a Web Service from the same domain.
What is the best way to approach creating a web service in this scenerio?
Do I add to this project or...?
You should be able to add an WebService file directly to the MVC project.
Right click on solution and select add new item, then select the web category and att the bottom of the list there should be Web Service.
Just remember to check that the routes does not eat up the call to the webservice.
That way the webservice can get access to the same model classes as the MVC application.
You can add a web service to the project just as you do in regular ASP.NET web apps, however, MVC basically IS a web service. You could create a controller that handles all the requests that you want your web service to handle.
With the advent of MVC it is quite common to do applications that only ever load a view once, then use AJAX and client scripting almost the entire rest of the life of the application. Your AJAX calls just hit up action methods for their goods and then use the deliciousness that is JSON to parse the data and utilize it.
In my opinion designing a web service as a controller instead of using [WebMethods] is far simpler and a lot more fun!
First, the question is "what do we mean by web service?" This can mean anything from a MVC page that responds using XML, JSON or some other agreed upon format to full blown SOAP and WS-* encumbered nightmares.
Anyhow, perhaps the best place to start is the WCF restful services -- these play very nicely with MVC, including routing.
The cool kids are using openrasta.