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?
Related
I have an ASP.NET MVC web application working with Entity Framework and I have the same database schema in two different database engines (Oracle and MySQL). The database is the same in Oracle and MySQL. The application should work with this two providers because I have two different scenarios.
When I want to work in the Oracle Scenario I have to change manually the Web.Config to put the correct ConnectionString, the correct provider for member authentication, roleManager ..., and I have to delete the Database Model (edmx file) and recreate it for Oracle.
When I want to change working from Oracle to MySQL I have the same problem. I have to change the web.config to put the correct providers and the connection string and I have to recreate the database model (edmx file) for MySQL model.
Is there any way to avoid this heavy and boring task every time that I want to change the database?
Basically it is possible to create multiple Web.config and to automatically select the right one depending on the current used environment.
Additional information can be found here.
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'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 all my entities in a seperate project in my edmx file and I expose them to my client application using a WCF service.
That means I don't have to give my client app a direct link to the project that contains the edmx file. That would be bad because it contines the object to query the database with.
But only the entities that my WCF service uses can be accessed from my client app. So for example because I have the following code in my service:
public MyClass GetMyClass()
{
return new MyClass();
}
.. I can use access MyClass in my client app with something like:
myServiceInstance.MyClass cls = new myServiceInstance.MyClass()
What about if I have an entity called MyClass2 in my edmx file that I want to use in my client app! How to I instansiate it without giving my client a direct link to my edmx file project or making a usless method in my service layer that returns MyClass2
What are other people doing?
Thanks a lot
We created a separate project with Domain Transfer Object Classes that served as Data Contracts for our various internal WCF services. We then shared the contracts project with those internal services. We had one data service; those methods would translate these domain objects to/from entity objects before/after storing/retrieving. Meanwhile, the external services made use of the standard proxies generated from XSD and WSDL files, and translated to/from the shared domain transfer model.
We had to do this because the object context is not (yet) portable over WCF, unfortunately.
Some considerations for your situation:
If your client app is external to your system, it should not know anything about your EDMX or its classes. It should only know about your WSDL and XSD.
If your client app is internal, then it is no use trying to share the entity classes in EF v1 because it is not supported properly, yet. You need to transfer more than just the classes/objects - you need the context too, which maintains change tracking, and it cannot be done via WCF directly right now.
If the WCF service doesn't use it, what would you want it for? A WCF service (itself) is purely for data transport - the "mex" approach for metadata doesn't share code, so your MyClass2 would be impotent. If you want, you can use assembly sharing at the client, but I really don't recommend this in this case; EF objects at the client is a mess... (plus it won't work on the lightweight frameworks like Silverlight, Client Profile, Compact Framework, etc)
Another option is ADO.NET Data Services; this works over WCF, but gives you a more LINQ-friendly API than the regular WCF approach - and any domain objects that your model exposes should be available on the client data-context.
If you want to do it the "proper" way, you should be creating special classes for your messages that are going across the wire, rather than trying to reuse business entities or data objects as messages. The value in this is that you are then free to change your business entities and data objects without worrying about the contract you have exposed to consumers changing. Every change to your service is a bit more deliberate since it happens independently of changes to data and business logic.
Another way to handle this is simply to use svcutil (or "Add service reference..." though svcutil works better for multiple service endpoints) to generate all the classes that the client will be using instead of adding a reference to the server project. That way, the only classes your client will ever see are the ones exposed by the service.