I need a both a Web API project and a function app project which share the same services / class libraries etc. A few questions
Is it bad practice to place them both in the same solution (or should they be in seperate repositories
Should the services be registered in the Startup class of the Web Api or the function app, or a mixture of the 2? Is it okay to register services only used by the function app in the web api startup class as this would make life easier? The services will do similar things and in some cases the same services will be used by both.
I am likely to only require a few timer trigger functions, most of the application will be build on the web api.
Specifically, the rest API will serve a frontend UI and the function app will provide updates to products on timer triggers.
Thanks for any guidance in advance and apologise if these are silly questions!
For #1 - I think it's totally fine to have them both in the same (git) repository - you might be following a monorepo strategy, OR these projects might be closely related e.g. part of the same business domain/capability where you might have something like a a core Web API project (ASP.NET Core WebApi) as well as some Function App event handlers (in a Function App project) that respond to external async events and invoke the core Web API. Alternatively, if they're completely unrelated repos and you're not following a monorepo strategy then maybe they should be in separate repos.
For #2 - some services might be exclusive to the ASP.NET Core WebApi, some exclusive to the Function App, and some might be shared. Assuming all the code is in the same repo; for the shared dependencies, you might consider having a third 'class library' project in the same git repo that can be referenced by both the ASP.NET Core WebApi project as well as the Function app project. This 'class library' project could contain all the shared dependencies. Dependencies should be registered in the startup of both the Web Api AND the function app.
I have a .NET solution which has two projects:
WPF project for the WPF application
ASP.NET WebApi project with a few controllers
I want to host the WebApi inside my WPF application (using OWIN). Any idea how can I do this?
If I create my controllers in the WPF project itself then I can host them using WebApp.Start (and pass a config class).
Here's an example of how to make a desktop application with OWIN and WebApi http://www.codeproject.com/Articles/869223/ASP-NET-Web-Api-Create-a-Self-Hosted-OWIN-Based-We
It's true that it's a console based application but you could use that in the bootstrap of your application to start the OWIN server when the app starts.
I would also advise trying it in a new test project until you get a hang of it before starting to create api controllers and mapping out routes
Yeah. Start reading documentation. Then "just go". This (self-hosting) is exactly what OWIN was designed to do and it is all documented.
IN your app at one point you will configure and start an OWIN based server. Contrary to how you do normal web apps, you can abandon the WebApi project - all controllers etc. can live in an assembly. Reflection is used to find them.
Is it possible to use a self hosted signalR server with an MVC(4) application such that it is totally seperate from the signalR server?
I tried Tim and Patrick's beautifully executed SignalR intro tutorial, and was wondering if I could try that? And even if I could, would that offer any performance advantages over an integrated service as is metioned in the tutorial.
It is absolutely possible to self-host a SignalR 2.0 server with OWIN and accessing this server from within any Website (which may be a MVC application). The only thing you need is to enable CORS (app.UseCors(CorsOptions.AllowAll); in your Startup file of the Owin Host) since it's not on the same domain as your Website. Obviously you can't use SignalR within the MVC application itself this way (e.g. to publish messages).
I'm using a self-hosted ASP.NET Web API 2 and SignalR 2 server with OWIN to serve data to clients. You can find an example server using this scenario here. Tho advantage in this approach is to have your views & styles sepparated from your data and business logic. Making everything very easy to cache and scale.
I'm just starting a project where I would like to use Kendo UI (based on jquery) with C#. A few weeks ago I was successful in handling requests using Web Services (asmx), was pleased with the results and performance, and was able to create forms quickly.
Since this is a new project, I thought I could look into different concepts such as MVC and WebApi. I found MVC to be the most complicaded so I went for WebApi and started playing with controllers and requests. So far what I'm finding (don't judge me, I'm new to these new concepts), is that Web Service seems to be simpler and more flexible.
So I guess what I'm looking for is... what are the main advantages of using MVC vs WebApi and even vs Web Services. Are there any downsides to Web Services? Would it be a bad practice to have my data layer controlled by Entity Framework, all models defined, and my requests handled by Web Services?
Any clarifications are welcome. Thank you.
In a broader sense, Web API is used to create Web Services ! It uses HTTP as its standard for creating services (instead of SOAP like in asmx) as its more open and any type of client like a mobile app, desktop app, web app etc will understand HTTP protocol. Another advantage is that u can easily use JavaScript/jQuery to communicate with your Web API. With SOAP web services, its a nightmare!
Kendo UI and Web API is a great combination. We have recently created a mobile iPad app using this combination and it worked like a charm. We also used Entity Framework with oracle as back end DB and it never gave any issues.
Webservices are nice if you have the need for it. A need as in needing that logic/data in more than one different type of application (such as web, and a mobile app, and a desktop app). (Or if you want to sell the service you're providing)
Using a webservice for ONLY a website which you don't except to expand to other things is complete overkill.
Furthermore, the MVC framework and the Web Api framework are pretty similar except web api is used exclusively for webservices. Coding in both of them will be the difference between white bread and wheat bread.
I am creating a new MVC4 project, and research has lead me to believe that communicating from javascript to the server side is better achieved now through web API framework rather than controller actions. Is my understanding correct on this?
I am presuming that I can share all my attributes etc between web API and MVC controllers so on the face it, it does not seem a massive change for me.
When I am setting up applications, I like to split components out in to projects. My plan was to have a MVC project and a web API project. But I have ran in to issues. For example I have ended up with 2 apps as such, separate routing set up etc etc.
So my question is, in a MVC application should the web API framework sit within the same project, or should the web API be separated into a project of its own and work around the issues?
Unfortunately you are wrong about that - I am presuming that I can share all my attributes etc between web api and mvc controllers so on the face it, it does not seem a massive change for me.
Many of the concepts used by Web API and MVC, even though similar at first glance, are actually not compatible. For example, Web API attributes are System.Web.Http.Filters.Filter and MVC attributes are System.Web.Mvc.Filter - and they are not interchangeable.
Same applies to many other concepts - model binding (completely different mechanisms), routes (Web API uses HTTPRoutes not Routes, even though they both operate on the same underlying RouteTable), dependency resolver (not compatible) and more - even though similar on the surface, are very different in practice. Moreover, Web API does not have a concept of areas.
Ultimately, if all you are trying to do achieve is to have a "new, trendy" way of serving up JSON content - think twice before going down that path. I certainly wouldn't recommend refactoring any existing code unless you are really looking into embracing HTTP and building your app in a RESTful way.
It all really depends on what you are building. If you are starting a new project, and all you need is to serve up some JSON to facilitate your web app - provided you willing to live with some potentially duplicate code (like the stuff I mentioned above), Web API could easily be hosted within the same project as ASP.NET MVC.
I would only separate Web API into a separate project if you are going to build a proper API for your online service - perhaps to be consumed by external customers, or by various devices - such as fueling your mobile apps.
IMO, security and deployment should drive your decision. E.g., if your MVC app uses Forms authentication but you're interested in using Basic authentication (with SSL) for your API, separate projects are going to make your life easier. If you want to host yout site at www.example.com but host your API as api.example.com (vs. www.example.com/api), separate projects will make your life easier. If you separate your projects and subdomain them accordingly and you intend to leverage your own API from your MVC app, you will have to figure out how to deal with the Same Origin Policy issue for client-side calls to your API. Common solutions to this are to leverage jsonp or CORS (preferably if you can).
Update (3/26/2013): Official CORS support is coming: http://aspnetwebstack.codeplex.com/wikipage?title=CORS%20support%20for%20ASP.NET%20Web%20API
After some degree of experience (creating API for apps and for mvc). I mostly do both.
I create a separate project for api calls that come from other clients or other devices (Android/IOS apps). One of the reasons is because the authentication is different, it is token based (to keep it stateless). I do not want to mix this within my MVC application.
For my javascript/jquery api calls to my mvc application, I like to keep things simple so I include a web api inside my MVC application. I do not intend to have token based authentication with my javascript api calls, because hey, it's in the same application. I can just use [authorize] attribute on a API endpoint, when a user is not logged in, he will not get the data.
Furthermore, when dealing with shopping carts and you want to store a users shopping cart in a session (while not logged in), you need to have this in your API as well if you add/delete products via your javascript code. This will make your API stateful for sure, but will also reduce the complexity in your MVC-API.
Steven from SimpleInjector (IoC framework) advises two separate projects: What is the difference between DependencyResolver.SetResolver and HttpConfiguration.DependencyResolver in WebAPI
I have recently done almost the same thing: I started with a new MVC 4 web application project choosing the Web API template in VS2012.
This will create a Web API hosted in the same application as MVC.
I wanted to move the ApiControllers into a separate class library project. This was fairly easy but the solution was a bit hidden.
In AssemblyInfo.cs of the MVC 4 project add similar line of code
[assembly: PreApplicationStartMethod(typeof(LibraryRegistrator), "Register")]
Now you need the class LibraryRegistrator (feel free to name it whatever)
public class LibraryRegistrator
{
public static void Register()
{
BuildManager.AddReferencedAssembly(Assembly.LoadFrom(HostingEnvironment.MapPath("~/bin/yourown.dll")));
}
}
In the MVC 4 project also add reference to the Api library.
Now you can add Api controllers to your own separate class library (yourown.dll).
Even if your project is so complex as to warrant two "front ends" then I would still only consider splitting out webapi into a separate project as a last resort. You will have deployment headaches and it would be difficult for a newbie to understand the structure of your solution. Not to mention routing issues.
I would aim to keep the system.web namespace isolated in the one "presentation layer". Despite the webapi not being presentational it is still part of the interface of your application. As long as you keep the logic in your domain and not your controllers you should not run into too many problems. Also, don't forget to make use of Areas.
In addition to setup the separate DLL for the Web.Api.
Just a Suggestion:
Create the Project
Nugget WebActivatorEx
Create a a class Method to be called upon app_start
[assembly: WebActivatorEx.PostApplicationStartMethod(typeof(API.AppWebActivator),"Start")]
[assembly:WebActivatorEx.ApplicationShutdownMethod(typeof(API.AppWebActivator), "Shutdown")]
Register a web.api routes inside the Start Method
public static void Start() {
GlobalConfiguration.Configure(WebApiConfig.Register);
}
Reference the Project to the Web Project. to activate the Start Method.
Hope this helps.
I tried to split the API controllers into a new project. All I've done is to create a new library project, moved the controllers inside folder named API.
Then added the reference of the library project to the MVC project.
The webAPI configuration is left in the MVC project itself. It works fine.