Here's my situation, I'm trying to create a WPF application that connects to my own web odata service (uses web api and entity framework). I have my own set of domain models/entities in the server side that the web api and entity framework works with. When, I add the web odata service reference in the WPF client side, it can't recognize my own domain models/entities and it looks like it creates its own set of it. Is what I'm trying to do even possible or am I just missing something?
Regards,
Raymond
Drive-by answer (unchecked): I remember reading that it wasn't possible at least a few weeks back. You might want to search the Uservoice site and the official forums for current status, or wait for a better answer here.
It looks like this problem is currently a feature suggestion for WCF Data Services (thanks to tne's uservoice link). The direct link to the request is https://data.uservoice.com/forums/72027-wcf-data-services-feature-suggestions/suggestions/3220086-allow-re-using-entities-from-another-dll-on-the-cl.
Related
First off, I apologise if this is a trivial question but I am getting so confused by the information I am reading. I have put off posting on here as I feel my question is too broad but I can't find a definitive answer. I am a C++ developer by trade but I am wanting to get into web development.
My end goal is to have a web API that is consumed by both a web app and mobile app. I want to get the structure nailed first by developing an web API and web app and then expand it to a mobile platform later on.
My aim is to have 4 separate sections - Database -> WebAPI -> Web App
-> Mobile App
all of which are protected with username/password etc.
I have decided to use ASP.NET Core but when creating an application I am given two options in visual studio - ASP.NET Core Application or Web API. I have tried creating a Web API and a separate Core Application but can't work out how to call the web API. I have also tried creating a Core Application as it seems like I should be able to do everything I want in one project but I am worried that the Web API won't be separated enough to be able to call from a mobile app.
I will be working with a database containing sensitive information so obviously want to protect access to the Web API and Web/Mobile app. I have been watching courses on Pluralsight about Identity but I have read that it doesn't work well with Web API's.
Basically I am getting extremely confused when in my mind my end goal should be relatively simple to achieve. If anyone could give me any pointers as to what technologies I need to use would be fantastic.
ASP.NET Core WebAPI is specifically designed for building REST-ful services.
ASP.NET Core Application is used to create web applications that returns both views and data (it's an analog of Asp.NET MVC from standard Framework).
Which to choose is really depends on kind of WebApp you are going to use. If you plan to use some SPA framework, you don't need mechanisms to generate views on server side - WebAPI is a great choice, otherwise choose Application. Here you can find more details on differences.
As of security concern, there no issues with WebAPI. It provides a lot of mechanisms to secure your API and restrict access to methods based on user's identity. Please look at this article as an example.
I would like to expose the SQL Server Views via OData Web API but I don't want to create separate controllers for each views as there are too many of them and they will only accept GET verb for all the views.
I thought I can achieve this using BreezeController but it looks like I cannot as it is obsolete now (The package which has BreezeController attribute is marked as obsolete).
Is there any way to achieve this with OData Web API that works with BreezeJS?
The [BreezeController] attribute is not obsolete. In fact, it is central to the "happy path" Web API controllers you see in the Breeze samples. I wonder what lead you to think otherwise? What package are you using?
I'm referring to the ASP.NET Web API!
The ASP.NET Web API OData is a different matter. Despite "Web API" in the name, that is almost a completely different approach to server development with its own behaviors and wire format. It does not use the [BreezeController] attribute and never has.
I'm not sure what you meant by "view" in your phrase, "separate controllers for each view". I think you mean what I would call "type". For example, in OData you'd expect a "Product" endpoint for your Product entity type.
AFAIK, the Web API OData approach demands a separate controller per type. That's what Microsoft's Mike Wasson says in his tutorial. He writes ...
A controller is a class that handles HTTP requests. You create a separate controller for each entity set in your OData service.
BreezeJS supports Web API OData too ... although there are limitations imposed by the current Microsoft implementation that may give you pause.
We are working through these with the OData team and hope to have better news in the coming months.
I have built a few WebAPIs since it was born, including one supporting OData URL filters when that was new. I see now that OData over WebAPI has matured, I see it can serve service metadata.
Is it complete enough for Excel or other OData client tooling to plug and play as if it were a full WCF Data Service (ye olde Astoria)?
That's it. Thanks
OData V1-3 services can be consumed by the Data tab and Power Pivot data source import of Excel. While Excel's support for importing data from OData V4 services will rely on Power Query. That support is planned targeting early next year according to this: https://social.technet.microsoft.com/Forums/en-US/2169958f-9e2a-4fc2-a844-c0dce4c17a19/support-of-odata-v40?forum=powerquery
It is. In the past you had to do the right configuration or do a workaround to populate the OData feed from Web API correctly, to be able to consume it from Excel. Suprotim Agarwal wrote an excellent blog post about all the steps necessary to consume the feed from Excel, including creating and configuring the endpoint and what the steps in Excel are.
Well the title basically sums it up, I'm wondering if I can create an OWIN pipeline to my ASP.NET Web API. I want to do this so I can apply a base security layer that I can apply to all of my API service hosted on my service server. New to OWIN, love the idea
Yes. You can start with this http://nuget.org/packages/Microsoft.AspNet.WebApi.Owin/0.21.0-pre and then you will need an another package depending on what host you choose.
You will find below link helpful. It using Katana, an OWIN implementation for Microsoft hosts and the Web API framework.
http://www.strathweb.com/2012/12/running-aspnet-web-api-with-owin-and-katana/
Yes.
Also: If self-hosting Web API 2 using OWIN in a windows service, you can check out this example on GitHub: https://github.com/danesparza/OWIN-WebAPI-Service
It walks you through creating the service, adding OWIN using NuGet, and using attribute based routing in Web API 2.
I have a windows service that is supposed to send e-mails periodically.
Next to the windows service project there is an MVC 3 project that is sending e-mails with MvcMailer (beautifully).
I want to use the same engine to send e-mails for the windows service.
How should I do it?
Import the MVC binaries and create one controller and new views for this purpose? Will it work?
Saving it in the database and requesting my web project to send the e-mail might not be the best solution because the information is the result of a query and is too big to be sent in the request.
The only other option I see is to simply request the web project to do all the work but this way it wouldn't be beneficial to place the windows service in another service to save the site application resources.
How would you do it?
As an alternative to MVC Mail, ActionMailer.NET can now be used stand-alone outside of MVC.
The details are covered here
http://geeksharp.com/2011/07/06/actionmailer-0-6-released/
I would argue that calling a mvc mailer from the service might be an overkill. If the mvc project is supposed to expose sending the email API for all of your other solutions, then building a REST api might make sense. However, if you just want to bring the functionality of the action method to the windows service, then i would choose an in-process functional component. If you can refactor the logic of the mvcmailer action method into another assembly why not just do that and then include that assemlby as a depedency in your windows service solution.
If you can provide the over all purpose of the mailer and how it's used in the web scenario, it may help us to provide a better architecture.
Why do you think the query to send to mvcmailer us too large? If you have the mailer MVC project already working and exposed via a restful URL, that becomes your email service and simply call it as a web request from your service.
You can get around size constraints in your request That shouldnt be an issue.