I was asked to create Web API built on top of Dataverse database.
I know that Dataverse already has its own API and web service to access data, but at some point in the future we may want to move from Dataverse to another DB, that's why decision was made to build API on top of existing Dataverse API.
I am not very experienced in building APIs, but my first though was to start using Entity Framework with Dataverse (as I am more familiar with EF than Dataverse API).
Do you have any experience in this field, I mean accessing data from Dataverse by using Entity Framework instead of provided services (REST API, OrgSvc)? Does it make sense at all or should I use existing services?
Just connect to the TDS endpoint and access Dataverse as if it were SQL Server. I doubt that Reverse Engineering will work, so you'll probably need to hand-write your entities and/or SQL statements.
Note the TDS endpoint is read-only.
Related
I'm trying to use Entity Framework Core with SQL Server (not SQLite) in a Xamarin forms app but I just can't figure it out! All tutorials explain how to use EF Core with sqlite! Are there any clear documentation or tutorials?
About connect to a Remote DataBase in Xamarin.Forms, I find one article that you can take a look:
https://xamarinhelp.com/connecting-remote-database-xamarin-forms/
You may be wondering why you couldn’t just connect directly to a database from your mobile app? The main reasons are:
Security
You don’t want your mobile client apps to have a database connection string with a username and password in it. It opens your database up to anyone. You can create a user with read only permissions and only allow access to certain tables, but they could still see all data in these tables. On an API, you can implement additional security checks and have authentication based on OAuth or an existing user management system.
Performance
Database connections weren’t designed to go over high latency connections. It is likely your database connection would keep dropping, forcing you to reconnect every time.
Control
With an API you can control the flow of data to and from your database. You can implement rate limiting, and monitoring of all of your requests. If you need to change business logic, or even what database or resources are used via each API request, you can do this on the server, without having to redeploy a mobile app.
Resources
With an API, you reduce the need for server resources. While you may have to setup another server to handle an API, the REST API is designed to be stateless and efficient. Scaling to many users in the future is easier with an API.
I'm calling Dynamics 365 through it's OData Web Api and I'm wondering which client library I could use to make programming easier.
My use case is that I mainly have to work with one entity: contact. I would like to retrieve some data, edit data and create new contacts. The other entity type I'm working with in a similar way is address. A contact can have multiple addresses.
Currenlty I'm using plain HTTP Client class for the communication to Dynamics.
I am developing a .NET Core application for Linux hosts, because of this I can't use the Dynamics CRM SDK (SOAP Endpoint).
My question would be what your advice is: should I use Microsoft.OData.Client or Simple.OData.Client? Or any other library?
I tried to use Microsoft.OData.Client and generated a client (proxy/wrapper) according to this article: https://blogs.msdn.microsoft.com/odatateam/2014/03/11/tutorial-sample-how-to-use-odata-client-code-generator-to-generate-client-side-proxy-class/
The problem with this is that it generates a .cs filewith 86 MB file size. Maybe it could be a solution to use this client afterwards, but it just seems so wrong to have such a big source file in our project. I would like to avoid it, but I didn't find an option to generate this If I accidentally open it, Visual Studio crashes, intellisense get's slow some times, if ReSharper is turned on VS is slowed down enourmously, etc...
I checked Simple.OData.Client and seems to have nice documentation and API. For instance: https://github.com/object/Simple.OData.Client/wiki/Retrieving-data
For Microsoft.OData.Client I didn't find documentation how to use it in a typed manner without generating the whole client. Is that possible? I only found this, where the generated context is used: http://odata.github.io/odata.net/v6/#04-01-basic-crud-operations
I think going with Simple.OData.Client seems to be a better option, but I would prefer to use a Microsoft library.
Do you have any reccomendations?
I have just implemented integration from .Net Core Web App running in Azure App services to Dynamics 365 Web API as a POC.
This included reading reference data ( joining different entities ) and modifying entities with referential data columns.
Full OData interface generation is problematic I found:
Could not find tooling that supports OAuth2 authorization and VS2019
Full interface definition inclusive of navigational properties / functions / actions and all entities with all fields becomes unwieldy to navigate and VS navigation is sluggish.
Depending on OData client you are going to use it will be sending much more information over the wire than needed and add complexity that is not in the spirit of the underlying REST OData service.
Generated code tools violated C# coding rules ( using reserved keywords like event, abstract and also generating members with same name as enclosing type ) requiring manual correction.
After much research I started using Simple.OData.Client as this allowed me
VS2019 / .Net core compatible toolset / runtime
Connect to Dynamics 365 OData Web API with OAuth2 bearer token
Write typed code in VS
Create only the entity models / navigational properties etc that I needed
Can select only the entity attributes you need to return instead of 200 ( smaller payloads )
You have to create the entity classes used in the typed fluent API yourself
Use DataContract attributes in case you want the CRM entity names to be different between CRM / C# code.
Simple.OData will then use the DataContract attributes when making up the Http call.
Unfortunately I didn't find the documentation all that insightful when I started looking deeper on issues like OAuth2 authorization and navigational properties but did find all my answers in secondary sources like github issues and some advanced tutorials for example
https://www.odata.org/blog/advanced-odata-tutorial-with-simple-odata-client/
Also using Fiddler to see the communications going back and forth is unbelievably useful in understanding what is going on.
Microsoft has introduced a Web API, a RESTful web service you can use to interact with data in Dynamics 365 using a wide variety of platforms, programming languages, and devices.
https://learn.microsoft.com/en-us/dynamics365/customer-engagement/developer/webapi/perform-operations-web-api
This is a new way of communicating with Dynamics 365 programmatically.
There are several libraries available that you can use. From below article, you can find those.
https://community.dynamics.com/crm/b/briteglobalsolutions/archive/2017/10/22/webapi-library-comparison-in-dynamics-365
I have personally used David Yack's library.
https://github.com/davidyack
Hope this helps.
Problem
I have a database in SQL Server. I want to use Entity framework 6 for the CRUD Operations and expose them through WCF Service so I can consume them in an Android Application and ASP.Net Application.
The problem although is that I cannot send the EF generated entities over the WCF Services (Even after setting the Data Contract and Data Member Attributes). Something I dont want to do is to create separate DTOs as they will limit the benefit of the EF as I will have to change them every time I change the database.
I have looked into WCF Data Services but I dont want the clients to query the database directly but to expose some methods, which can perform the CRUD operations, Return Lists of a single entity and so on. Microsoft here isn't recommending Self - Tracking entities : http://msdn.microsoft.com/en-us/data/jj613668.aspx
I will be having a 2 Tier Application, with one hosting the WCF and EF and the other being the Presentation Tier (ASP.Net Website and Android App).
My Question is, How and Which is the Best way to accomplish this task, without limiting the flexibility provided by EF 6.
I need to expose few OData end-points, for which there is no direct table to connect in my DB to get data and use data web service or Entity Framework.So I am developing it as a normal web service and returning List of custom objects.
Custom objects have DataContract attribute in the definition.
My question is, Is there any drawback with my approach?
YOu mean except odata clients not able to access your things (big no no) and you lacking ny ensible query semantics?
No, not really. It is a less functional and lacking standard solution ,but if that is ok with you.
Following the KISS principle, I suddenly realised the following:
In .NET, you can use the Entity Model Framework to wrap around a database.
This model can be exposed as a web service through WCF.
This web service would have a very standardized definition.
A client application could be created which could consume any such RESTful web service.
I don't want to re-invent the wheel and it wouldn't surprise me if someone has already done this, so my question is simple: Has anyone already created a simple (desktop, not web) client application that can consume a RESTful service that's based on the Entity Framework and which will allow the user to read and write data directly to this service?
Otherwise, I'll just have to "invent" this myself. :-)Problem is, the database layer and RESTful service is already finished. The RESTful service will only stay in the project during it's development phase, since we can use the database-layer assembly directly from the web applications that are build around it. When the web application is deployed, the RESTful services are just kept out of the deployment.
But the database has a lot of data to manage over nearly 50 tables. When developing against a local database, we can have straight access to the database so I wouldn't need this tool for this. When it's deployed, the web application would be the only way to access the data so I could not use this tool. But we're also having a test phase where the database is stored on another system outside the local domain and this database is not available for developers. Only administrators have direct access to this database, making tests a bit more complex.
However, through the RESTful service, I can still access the data directly. Thus, when some test goes wrong, I can repair the data through this connection or just create a copy of the data for tests on my local system. There's plenty of other functionality and it's even possible to just open the URL to a table service straight in Excel or XMLSpy to see the contents. But when I want to write something back, I have to write special code to do just that. A generic tool that would allow me to access the data and modify it would be easier. Since it's a generic setup around the ADO.NET Data services, this should be reasonable easy too.
Thus, I can do it but hoped someone else has already done something similar. But it appears that there's no such tool made yet...
You are referring to ADO.Net Data Services. It basically creates an Entity Database Model and adds a REST frontend to the service using ASMX. There is a How To article availble from MSDN here on consuming the service using .Net. I have also done the same thing using the normally WebClient class in .Net in the past.
You can also look at the WCF REST Starter Kit if you want to roll your own based on Entity Framework. The starter kit also contains a handy new WebClient class that can be used to communicate with REST services.
Clarification
There is no prebuilt application client that I am aware off which will talk to these service, since they are pretty much accessing the data using Web Services. There is the Microsoft Smart Client Factory which is most likely the closest thing I have worked with.
I mentioned the above 2 options since they already have libraries in .Net that work with them directly, either as a referenced Web Service, or for the more adventurious, myself included, using the WebClient library or alternatively the new HTTPClient library in the WCF REST Starter kit.
I have used both, in Windows, Web, Silverlight and WCF. The latter being the easiest since they are focussed at REST.
We are currently investigating Prism which strongly leans to using this method when using WCF for front-end development.
Assumption
With regards to this question, you are making a generic assumption that wrapping ADO Entity Framework with a WCF service it will be generic. ADO.Net Data Services is the closest you will get, however the structure of the database will fundamently change the way you interact with it. Going a level higher in a "generic" way would be dangerous, as these 2 technologies, individually or together, are already as generic as possible.
In addition to Data Services (+1), consider RIA Services. It's like a domain-specific version of data services for Silverlight or WPF clients. Less flexible, but easier, than Data Services.