I'm taking another project currently, which is based on the ADO .NET DS, and I need to get into the topic as quick as possible.
What is the purpose of ADO .NET Data Services in simple words? What is the best resource explaining ADO .NET Data Services?
The microsoft page on the topic has a fairly good summary -
http://msdn.microsoft.com/en-us/data/bb931106.aspx
This site also has a good intro
http://greggalipeau.wordpress.com/2008/03/21/introduction-to-adonet-data-services-part-1/
REST style web services for data access. By REST style, that means using HTTP GET/PUT/DELETE/POST instead of SQL DML, and for returning results it uses JSON and Atom Pub (an xml format kind-of similar to RSS) instead of a binary result structure and protocol like Microsoft SQL Servers TDS (the protocol used for sending tables back to clients).
Since it is built on top of the Entity Framework,i.e. the web service part is generated from a edmx data model, choosing to use ADO.NET Data Services is also choosing to use Entity Framework.
Related
I am having a bit of an issue with integrating with NetSuite API on .Net Core using VS2017 and it has no option to add Web Service. When I consumed their web service using add connected services some objects and classes are missing.
In .Net 4.5, the classes and object are available. My manager wants me to write the API in .Net Core.
I took the sample code from NetSuite and the very first thing is class NetSuiteService which has important Passport property for login.
Anyone had a solution to this?
It's fairly easy to integrate SuiteTalk with Dot NetCore, all you need to do is import the WSDL into .NetCore project via adding it as ConnectedService reference and it will set you up with WCF.
The DEMO code that NetSuite people have provided will not match the code generated on your machine. I would recommend you using TBA instead of other authentications.
(just copy paste the code provided by NetSuite's folks for authentication as that is the convention, you can change the crypt algorithm if you want to, just generate the Keys, put them in your configs and you're good to go)
Class "NetSuitePortTypeClient" will contain your endpoints for all types of communication to NetSuite web services.
Read the first 50-100 pages of the documentation manual that NetSuite provides for learning the conventions to be used throughout your journey.
Hope this will give you a headstart.
My application currently accesses SQL Server the "traditional" way - via EntityConnection on top of SqlClient. I would like to add the option of accessing SQL Server via a new OData service. Any ideas on the best way to do this? Is it possible to reuse the existing model-first EntityObject-derived classes? Thanks!
The best way would be to follow this tutorial to create an OData service: http://www.asp.net/web-api/overview/odata-support-in-aspnet-web-api/odata-v4/create-an-odata-v4-endpoint.
Update adding more details given the comment:
Although the link should be enough for answering the question, I can also elaborate on the end-to-end scenario a little bit.
Now the premium experience of creating an OData V4 service out of an SQL Server DB is to use the ASP.NET Web API 2.2 for OData V4. With the help of the code-first aspect of entity framework you can create an OData V4 service that supports pagination, queries, and CRUD operations in a very reasonable time (about 10 minutes for every table in your database).
As soon as the service is created, various client libraries that supports consuming V4 services can be at your service. The premium experience on the .NET platform is the OData v4 Client Code Generator.
If your consumer is a non-developer, Power Query can help you import the data from the OData service. Their support for V4 services will come early next year according to this, but Excel and Power Pivot already natively support consuming V1-3 services. For creating a V1-3 service, the tutorial next to the one I gave at first would help.
I am exploring OpenUI5 to use it as front end for developing SAP applications. One thing I noticed is that it is more user friendly with OData services/OData model. I believe, it may be a close initiative of Microsoft with SAP or vice-versa.
I am using Java technology along with JCo outside SAP environment. I am exploring for the best options.
Should I expose my Java services as OData services to leverage OpenUI5 capabilities?
1 I see that Java implementations for OData support is limited to Version 2 and Version 4 is underway. This community is very small, not surprisingly.
Should I limit the usage of OpenUI5 only for: application definitions, view definitions, layouts, etc. and use Java services (e.g. REST/SOAP)?
1 Here, I have to add my JavaScript/jQuery logic for the CRUD operations on UI controls. I am not sure how much of it is supported for plain JSON/XML objects if I push JSON/XML response from server.
Just to be clear, I hope you have a clear understanding of Odata and REST. The difference is that OData is a specific protocol; REST is architecture style and design pattern.
The OData protocol is built on top of the AtomPub protocol. The AtomPub protocol is one of the best examples of REST API design. So, in a sense you are right - the OData is just another REST API and each OData implementation is a REST-ful web service.
Odata is the way to go since with Odata Model & binding, the pain of writing a lot of javascript is reduced by a huge proportion.
I think you should keep it simple and use REST API and Json to communicate between your back end and SAPUI5 front end.
I really like OData (WCF Data Services). In past projects I have coded up so many Web-Services just to allow different ways to read my data.
OData gives great flexibility for the clients to have the data as they need it.
However, in a discussion today, a co-worker pointed out that how we are doing OData is little more than giving the client application a connection to the database.
Here is how we are setting up our WCF Data Service (Note: this is the traditional way)
Create an Entity Framework (E)F Data Model of our database
Publish that model with WCF Data Services
Add Security to the OData feed
(This is where it is better than a direct connection to the SQL Server)
My co-worker (correctly) pointed out that all our clients will be coupled to the database now. (If a table or column is refactored then the clients will have to change too)
EF offers a bit of flexibility on how your data is presented and could be used to hide some minor database changes that don't affect the client apps. But I have found it to be quite limited. (See this post for an example) I have found that the POCO templates (while nice for allowing separation of the model and the entities) also does not offer very much flexibility.
So, the question: What do I tell my co-worker? How do I setup my WCF Data Services so they are using business oriented contracts (like they would be if every read operation used a standard WCF Soap based service)?
Just to be clear, let me ask this a different way. How can I decouple EF from WCF Data Services. I am fine to make up my own contracts and use AutoMapper to convert between them. But I would like to not go directly from EF to OData.
NOTE: I still want to use EF as my ORM. Rolling my own ORM is not really a solution...
If you use your custom classes instead of using classes generated directly by EF you will also change a provide for WCF Data Services. It means you will no more pass EF context as generic parameter to DataService base class. This will be OK if you have read only services but once you expect any data modifications from clients you will have a lot of work to do.
Data services based on EF context supports data modifications. All other data services use reflection provider which is read only by default until you implement IUpdatable on your custom "service context class".
Data services are technology for creating quickly services exposing your data. They are coupled with their context and it is responsibility of the context to provide abstraction. If you want to make quick and easy services you are dependent on features supported by EF mapping. You can make some abstractions in EDMX, you can make projections (DefiningQuery, QueryView) etc. but all these features have some limitations (for example projections are readonly unless you use stored procedures for modifications).
Data services are not the same as providing connection to database. There is one very big difference - connection to database will ensure only access and execution permissions but it will not ensure data security. WCF Data Services offer data security because you can create interceptors which will add filters to queries to retrieve only data the user is allowed to see or check if he is allowed to modify the data. That is the difference you can tell your colleague.
In case of abstraction - do you want a quick easy solution or not? You can inject abstraction layer between service and ORM but you need to implement mentioned method and you have to test it.
Most simple approach:
DO NOT PUBLISH YOUR TABLES ;)
Make a separate schema
Add views to this
Put those views to EF and publish them.
The views are decoupled from the tables and thus can be simplified and refactored separately.
Standard approach, also for reporting.
Apart from achieving more granular data authorisation (based of certain field values etc) OData also allows your data to be accessible via open standards like JSON/Xml over Http using OAuth. This is very useful for the web/mobile applications. Now you could create a web service to expose your data but that will warrant a change every time your client needs change in the data requirements (e.g. extra fields needed) whereas OData allows this via OData queries. In a big enterprise this is also useful for designing security at infrastructure level as it will only allow the text based (http) calls which can be inspected/verified for security threats via network firewalls'.
You have some other options for your OData client. Have a look at Simple.OData.Client, described in this article: http://www.codeproject.com/Articles/686240/reasons-to-consume-OData-feeds-using-Simple-ODa
And in case you are familiar with Simple.Data microORM, there is an OData adapter for it:
https://github.com/simplefx/Simple.OData/wiki
UPDATE. My recommendations go for client choice while your question is about setting up your server side. Then of course they are not what you are asking. I will leave however my answer so you aware of client alternatives.
I am trying to perform CRUD against WCF Data Services (OData). The Read portion is pretty well documented across the web… it’s the Create, Update and Delete that I am having trouble with.
As for the documentation, have you looked at odata.org: http://www.odata.org/developers/protocols/operations#CreatingnewEntries
It has a description and samples of all the common CRUD operations against an OData services.
You can also write a sample client application using any OData client (for example the .NET one) and use something like fiddler to see what requests are being made against the service, if you need to see the exact payload shape for your particular service.
You can try this REST PowerShell module that Jaykul wrote.