This is more of an Architecture question, and I want to know all the possible pros and cons of the approach.
In my org, we have an ASP.NET Application, a Web API Project, and underlying DLLs which calls App Tier which is physically on different server. In ASP.NET Application, for a particular piece, we are having a SPA.
For most of the things (I would say 99 % of the things) , we are making ajax call from our SPA to Web-API to access underlying functionality.
SPA and WebAPI are both deployed and hosted on same Web Server as different applications and WebAPI has reference to underlying DLLs so these DLLs are deployed with WebAPI.
For one of the functionality some server side processing needs to be done on ASPX page's code behind.
I am suggesting to my team to do keep calling from SPA to WebAPI using http client and maintain loose coupling that we have between Application and the dlls via WebAPI, but many (I would say everybody else in my team) is in favor of adding direct reference of DLLs to ASP.NET application, so now these DLLs will be deployed with ASP.NET Application alongside.
Is my suggestion not so good provided ease of implementation that we would be getting with adding direct reference for DLLs in ASP.NET Application? Let me know if I am not explanatory enough.
I would be in favor of using a DLL directly if you could get rid of the Web API altogether. Since it does not sound like you are planning to do that, I think your suggestion to continue using the Web API from your application:
Using the DLL from two places creates a deployment liability: every time you update it, both places must be updated
Changing the code in DLL requires testing the change from two paths - A-D and A-W-D
Fixing a bug in the way that you call your DLL would likely have to go to both A and W, instead of going to W alone.
Of course, the path A-W helps you exercise your Web API component, too, helping you detect bugs early.
Related
I have to create a Web API for my existing MVC project and make API Controllers calling the Service Layer and Models, which is contained in separate projects but in the same Solution, then create and map to DTOs.
Layout of my Projects Solution in VS
( ignore the BookService.cs. I was just trying to do a WebAPI tutorial and I put it in the same solution temporarily).
I have been reading up on WebAPI and how it functions for the past 2 days, but I am not being able to fully grasp an understanding on how to create a API Controllers for my MVC project without referencing it? I also have to make Views at the end, in my main project calling the uri, but I am very confused at this point.
It would help me out a lot if someone can please clarify how I am to tackle this or point me to a tutorial or some sort of source to learn the process of working with Web API. Thank you.
The Web Api project will be a separate "website", that you will need to host individually. Your MVC project will make requests to the Web Api using HttpClient.
Since the Web Api will be separate, you won't be able to utilize helpers like Url.RouteUrl, etc. to get URLs for the Web Api actions. You will also just need to know the full URI to the Web Api, including it's domain. There will be no way to programmatically ascertain this information, so I would recommend making use of Application Settings to avoid hardcoding in your MVC project.
Right-click on your MVC project in the Solution Explorer and choose Properties. Then click over to the Settings tab. Here, you can add strongly-typed settings that your MVC application can utilize. Importantly, these settings are still persisted in the Web.config, so you can change them using config transforms. Your Web Api will likely have different URLs depending on whether you're in development vs. production, for example, so that will make it very easy to ensure that you're hitting the right thing in the right environment.
You can add a setting like WebApiUri, and give it a type of System.Uri. Then, set it to the string value of where your Web Api is hosted in development, i.e. http://localhost:12345. It's important that the setting be specific to your development environment, as config transforms are not applied in development. For staging, production, etc. you'll change this setting appropriately in the applicable config transform, and it will be updated to the right value for the right environment when you publish.
Then, when you need to work with it, you'll just do something like:
var client = new HttpClient();
client.BaseAddress = Properties.Settings.Default.WebApiUri;
Then, just make requests as normal through the client. For more information on working with HttpClient, see the documentation.
I maintain a website written in ASP.NET MVC 5, and hosted in Azure. It's a legacy app that is a real nightmare to maintain, and so I've been asked to start migrating to a new codebase and the ASP.NET Core framework.
Our goals are:
Migrate one page at a time
Don't lose the "F5 debugging" experience in Visual Studio
My initial thought was to use a virtual application/directory, which is supported both in Azure and in IIS Express. The idea is to point, for example, the /Shop page to the new website by using a virtual path. Then when we're ready, move the /Team page and so on. I would add a virtual path for each migrated endpoint until the migration is complete.
To accomplish this I created a new ASP.NET Core project, and I've been trying to edit my applicationhost.config file and trying to start multiple projects from Visual Studio, without luck.
I tried configuring two sites with the same port binding, two apps within a <site> tag and also two virtual directories within an <application>, but I always end up with errors. Either I can't start debugging (Can't connect to IIS Express or The object invoked has disconnected from its clients messages) or I get a 502 error.
I don't even know if this is going to work in Azure, but I know we can't go down this path without proper development experience.
Am I missing some other, better solution? If this is a good solution, is there any way to make this work in Visual Studio?
I would consider creating multiple new websites in Azure, one for each section. Then, as I start working with Shop, for example, I'd leave an almost-empty controller in the original solution, redirecting to your new Sales web site. Using this approach, you can efficiently work with one smaller code base at a time and in the future scale the individual pieces of your site as needed. Please note, that you can host multiple sites within the same app service environment (thus not incurring a lot of extra cost by separating into multiple processes).
Best of luck :-)
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 want to access a remote SQL database for my Silverlight client. I know that there are various ways to do this (Entity Framework model, Linq to SQL), but all of those rely on something in the web project (or, at least, all of the tutorials I've read do). What's unusual for me is that there is no web project, which of course prevents me from using various assemblies.
The only thing I do have which might be useful is a WCF service running on IIS, which will have less limitations (and I can add that as a service reference in my SL project). But I'm not even sure if this is a feasible option for this problem.
Any solutions or suggestions would be great.
Thanks.
Edit: Thanks for the suggestions guys, but here's a little more: I am making an individual XAP that is loaded into something else (someone else's project is importing and loading the XAP files), so I don't have access to the web component. The loader itself will be hosted within a website (at least, I assume it will be).
I already have a WCF service set up which is currently hosted in IIS, so I can potentially create something here. How? Well, it seems I can generate the ORM classes using SQLMetal.exe, and then import that code into the WCF service. This will allow the service to make calls to the remote database and have that data returned in C# classes. The perhaps I'll make those data classes as ServiceContracts and pass the data that way. What's the problem here? Well, to be honest, I'm not really sure how it would work. I mean, I call the WCF Service from the SL application, which does its thing. It then must contact the SL application (I have no idea how to do that part) and send along a load of data. It would be great if someone had has experience of this and would offer some suggestions. I know it's not really how you're supposed to do it, but I've drawn the short straw so I'm stuck with it.
Ok, so if I understand it correctly, you use a Silverlight application (XAP) which is started locally from a network share or something? Because why would you not have a web project when using Silverlight? (is there no server available to host it?)
But ok, when that is the case, you can access a WCF service from Silverlight. However it has some limititations. For instance you can only use asynchronous calls to the service, and you can only use WCF basichttpbinding as binding for the WCF service.
See: http://msdn.microsoft.com/en-us/library/cc197959%28v=vs.95%29.aspx
First, I would recommend you use WPF instead of Silverlight for this project. If you're not using this as a web client, then WPF is a million times easier / better.
But if that's not a possibility:
You can write a self-hosted WCF service and run it somewhere accessible. Self-hosted will allow for WCF connections to connect without the IIS necessary. In your self-hosted program you need:
Front end WCF defined
Back end SQL database
Depending on how smart this client needs to be, a BusinessLogic layer to transform the data from WCF to SQL.
Silverlight is sandboxed, so it can only access its own Web application. Therefore, your best bet is to include a WCF or ASMX web service in your web application that handles the DB access.
If you don't want to run a sandboxed UI on a Web application, you cannot use Silverlight but should use WebForms or Windows Presentation Foundation (WPF) instead.
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.