I have an asp.net mvc application and now I need to add a web service to go along with it. What is the best solution for this? Just create a new web service project and add it to my solution then deploy it to the same web server using a different url? I would like it to be a part of the mvc application only because I have all my database code in there.
Any suggestions would be appreciated. Thanks.
There's no reason not to add a web service project.
You state that all your database code is in your MVC project. I strongly recommend you remove it from there into a separate class library project. This third project would be used both by the web service and by the MVC application.
I also strongly recommend that you not use ASMX web services for any new development.
Use WCF only, unless you have no choice at all. There's a misconception that WCF services don't do SOAP - they do, and WCF has replaced ASMX.
Web service could mean a soap based web service or a RESTful web service. I can't think of any reason why you would not be able to simply add an asmx file to your project and be in business. That is the soap based route. If you want to be really cool though you can simple return xml from a controller action and implement a RESTful solution right over the MVC framework.
If you want to use a regular ASP.NET asmx web service, it's certainly possible. Here's an example from Scott Hanselman that does just what you are asking about and it throws in some other ASP.NET technologies for good measure.
All you have to do is File -> New Item -> Web Service and it should work like a regular ASP.NET application in your Mvc project.
i think there's a couple of things here.
you can indeed add a web service to an MVC application. you may even consider identifying the web service(s) as a script service to make REST like operations easier to perform via javascript. this may not be necessary due to your circumstances.
i think there is a stronger question as to the underlying architecture. If you are placing the web service withing your mvc application, because, your database code is already there...should it be? it might be a good time to abstract your data layer out a little. However, if you're dealing with a relatively small project and don't need the flexibilty, then certainly, add a web service right in. i guess what it really boils down to is addressing the true needs of your application.
MVC is built on the asp.net framework. You should be able to include a web service within the same project. I haven't done it but I know that you can combine asp.net forms applications with MVC applications in the same project. The same should go for web services.
Unless your application is very small I would recommend you create different projects for each logical part of the application. A good staring point is having a project for each of these:
Domain objects
Data access
Web Services
UI (your ASP.NET MVC app)
This provides a clean separation corresponding to your architecture and supports reuse.
Related
I'm mostly back end developer and want to start small side project.
I want to do razor pages web app and as a part of it I would like to have web api that can be consumed outside of the app and if I want, use it to build other front end with it.
What would be good project structure? I don't want to have it deployed as 2 apps. One for razor, second for web API. I would like to have it as a one deployed app.
Is this good approach?
Thanks
I tried separate razor pages app and separate web api. Deployed as two pages.
Since you're building a Web API project anyway, you should consider making a frontend application with a framework like Vue that interacts with the API, instead of a Razor project. Having both a Razor project and a Web API project would be redundant as both of them would have to incorporate most of the same backend code.
It better separates the role of the frontend and backend applications, and Microsoft's documentation suggests using this project structure too.
You'd have to deploy two separate apps, but this would be a more suitable approach.
If you still want to deploy one application only, you could just incorporate Web API services in your Razor app, but this really isn't recommended.
Hello Stackers,
I have an Asp.net Mvc and i wanna migrate the index page from it to an Web Api
i wanna know if there is any pattern or approach to follow for making it more easy.
i google it but i didn't found a useful answer.
Any answer will be appreciate it.
Thanks
I am not sure if there is a pattern, but next some steps that could help.
Group all your services that returns, saves, delete or do some work in the backend. On your backend you could create a new layer (New project or new namespace) to call the existing ones and export those services as Web API endpoints.
On your frontend check how are you going to consume your Web API services. I mean if you are going to call it directly with javascript or maybe using some library or framework.
Those are going to be the first steps.
I have an ASP.NET Core (.NET Core 2.2) app structured with the following projects:
API: this is meant to represent a WebAPI (with controllers inheriting ControllerBase)
Services: This contains services which the API controllers utilize to access the database, etc
Database: This contains the usual DB repositories, which the services layer utilize to access the database
Now, I want to add a UI that talks to the API (the MVC part pre-.NET-core). How is that accomplished with .NET Core, where MVC and WebAPI are one of the same thing? Should MVC controllers/models/views be part of the API? Should it instead be a new project that listens on a different port? How does authentication fit in for both (e.g. APIs usually have some token-based authentication, UI apps usually have username/password authentication)? Should the WebAPI and MVC portions share the same authentication like ASP.NET Identity? Wouldn't that tightly couple the two if they use the same database?
Is there some kind of Microsoft or community suggested convention/documentation for how to structure such projects?
How is that accomplished with .NET Core, where MVC and WebAPI are one of the same thing?
In dotnet core MVC and WebAPI can be present in the same project. Everything application is like a console application. You can add MVC services to startup class to make it an MVC application.
Should MVC controllers/models/views be part of the API?
Its better to have different controllers for MVC and WebAPI related functions separately while keeping them in the same folder.
Models - They can be reused for both mvc and webapi. Same for view models and DTOs.
Views - Just for MVC, webapi does not require views.
Should it instead be a new project that listens on a different port?
Yes, you can create a different project for webapi and MVC.
How does authentication fit in for both (e.g. APIs usually have some token-based authentication, UI apps usually have username/password authentication)?
If you use token-based authentication then both web API and MVC will be able to use.
Should the WebAPI and MVC portions share the same authentication like ASP.NET Identity? Wouldn't that tightly couple the two if they use the same database?
If you use ASP.Net Identity with identity server then both MVC and webapi will be able to share the same authentication mechanism without tightly coupling.
I think that you are a bit confused about WebAPI compared to MVC.
You can see WebAPI as simple web services answering http request with data (whatever the data is, it could even include javascript or assets).
EDIT:
So sending "UI" informations is definetly a part of your API and Service project.
On API you will need to create dedicated controller(s) to send back your "UI" part(s).
On Service you will need to create dedicated service(s) to fetch the "UI" informations (their is many way to do this, using Ressources, fetching data on Cloud, etc)
EDIT2:
But nothing prevent you from creating an entirely different solution for UI parts. If you chose WebAPI again, you will still need to enforce the previously mentioned API/Service logic. It's up to you to chose whatever you feel confortable with.
The answer to your question is mostly, "it depends on your tastes" but in my opinion...
Unless you are planning on exposing the API to other applications, keep the API controllers in the same application that hosts the MVC controllers (or Razor Page). When I have both MVC controllers and API controllers I put them under separate folders. I think this is OK, because your controllers should be very thin. I generally put all the business logic (including any necessary data access) in services that are built in a separate class library.
You only add an API if you actually need it.
Do you plan to expose anything to another app?
If all you want is a UI which interacts with a database then don't bother, use the services to retrieve the data, called them from the MVC controllers and skip the API part completely.
You don't need an API for such a limited use case. An API introduces a host of other things to consider, like authentication and security.
Don't complicate things when you don't need to.
I'm looking at working my long-standing API to run on IIS rather than in a desktop app as it is now. Everything on the API is working so I'd rather not change too much if I don't have to. I know about the new Web API template in ASP.NET MVC 4 and I've worked with it, but I found that it didn't give me the control over everything that this particular project needs.
So my question is, is there any way to build an application for IIS that has something like an entry-point where I can just get a web request then use entirely my own code from there? Or do I have to build something that uses the Web API?
Yes, you'll want an ASP.NET handler.
How To Create an ASP.NET HTTP Handler by Using Visual C# .NET
http://support.microsoft.com/kb/308001
You'll need to handle parsing the request and serializing the result yourself. It's probably much better to create a web-api facade in front of your services than trying to do it manually.
I am a total newbie to the WCF world. I have an ASP.net (v4) website running on our dedicated windows 2008 server box. I'll refer to the website as, webisteA.com
I'm creating a new website, websiteB.com.au and I'd like to expose the functionality in WebsiteA.com to the new site. Things like logging in, registering in the database etc.
I think the best way to do this is to create a WCF service which sits in WebsiteA.com - but I am struggling to find any tutorials on how to do this. There are lots about creating a new project, but not that many about adding a WCF service to existing websites.
Is this the best way to do it? In the future I'd also like to use the service for mobile apps in the future too - not sure if that will make a difference.
OR - do I create a new service in a new app which is totally seperate to websiteA.com and websiteB.com and host this as website0.com and expose the database via that?
The questions I don't have answers for are...
is it restful? Do I use XML or JSON?
Baiscally, I want to be able to use it like an API - for example, saying "show me all the members who meet criteria X".
Thanks for any information.
ps) I have visual studio express 2010 c# (and a trial of studio pro)
You can certainly include WCF within the website A project - but have you considered the ASP.NET Web API? I haven't used it yet - but did use the earlier WCF Web API which spawned it.
Neat features include Content Negotiation (if the client asks for XML the API sends XML. If it asks for JSON is gets JSON) and a lot less config cruft (WCF web.configs are dreadful and completely overcomplicated IMO)
It's probably a lot easier to make a RESTy API with the ASP.NET Web API than with standard WCF.
A great open-source .NET solution is NancyFX which is really worth a look too.