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.
Related
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.
I'm going to create an application consisting of 2 modules.
Server side based on asp mvc 3 services. This is supposed to provide data from a sql server database to a bunch of WP7 clients.
Client side on WP7. This one is supposed to retrieve data from the server and store it in local database.
I suppose it's a good idea to have only one set of models for both of those apps and I'd like to use Entity Framework.
I'm considering the following approach:
Put these 2 projects on one solution. In server side app generate Entity framework models form a sql server database. Use them in both apps.
A service on the server should use the model to retrieve data and than return them as an oData xml. The WP7 app should grab this oData xml and using the same models store it in local database.
I've never done anything similar before so I'm not sure if is a good approach. Will it work? Any remarks appreciated.
EDIT
I already have a working service returning data. I also created a test SL app which grabs data. I uses the Entity Framework models from the server app. The next step is to create a WP7 app, grab the data to Entity Framework model (the same way as in SL app I mentioned before).
Here you can see how I create a read context through a service:
svc = new BlogContext(new Uri("/BlogService.svc", UriKind.Relative));
var q = svc.Blogs;
But there still is a problem I don't know how to solve. How to create a context to write to a WP7 local database?
Yes, it can work; I'm doing something very similar in one of my apps (albeit swapping oData for a JSON/OAuth API)
You probably want to use something like Project Linker to get a multi-targeted solution, because libraries are not shareable between Silverlight (WP7) and the server (.NET).
Stick to POCO classes, and use the EF POCO class templates exclusively. Use the EF models themselves only on the server. I don't think you can use DataAnnotations in Silverlight, so you may need to roll your own validation.
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.
I have a client application (WPF, C#, .net4) which uses POCO entity model connected through SQLITE provider. So I want to have same entities from this project in an asp.net project (with MSSQL provider), to use there the same entities that I use in my client application. I want to create some kind of replication functionality between my client app (SQLITE) and web server (MSSQL) using same poco model using web services.
So I have a reference to my entities model in both projects with different connection strings for edmx files. And in this case (because edmx was compiled for sqlite provider) when I'm trying to use mssql data provider I get an exception:
unable to cast System.Data.SqlConnection to System.Data.SQliteConnection
So my question is if it is possible to use different data providers in one entities model?
What is the best way to use same model in different projects?
If I understand your question correctly, then if you are looking for your EF model to support multiple database implementations then this is not possible out of the box. The SSDL file auto-generated by EF will contain provider specific metadata and therefore will restrict its independence from the different database implementations you are using.
There are some articles out there providing ways around this, but this requires a separate copy of your model for each provider and hacking the generated XML with the provider details.
with POCO it should be possible.
As long as web service is passing xml or json data, it will not be bound to any specific data connector implementation. I am not sure what it will be in binary mode - possibly there's some link to data model.
Are you getting this error from WPF app or from web service? It sounds like you are trying to test this inside client app still. Did you try implementing web service yet?
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.