I have a solution containing a WPF Project and a Windows Phone Project, both having a reference to my PCL that contains my Models and ViewModels. I also have a WCF Project that allows me to call a common API. It worked just fine so far.
Now I want to use Entity Framework to communicate with an SQL database so I can make request from my ViewModels. I thought about moving my Models from the PCL to the WCF project, and use them as entities. This implies to reference my WCF project in the PCL.
Just like specified here: Entity Framework for Portable Class Library , I get the following error:
"Failed to add reference to 'System.ComponentModel.DataAnnotations'. Please make sure that it is in the Global Assembly Cache."
which is in reality a Nuget issue. (http://nuget.codeplex.com/workitem/2978). The real reason is that Entity Framework is not compatible with PCLs anymore. From what I read, the Entity Framework 7 will allow me to do so, but it's impossible for now.
Does anyone know a good way to communicate with my database with this configuration ?
Here is my solution:
My Models and ViewModels are still defined in my PCL. Entities are defined in the WCF. I added a class in my WCF that converts an Entity to a Model. An interface that defines each available request to the API in the PCL, and I'm implementing this interface in each platform. Each platform implementation just calls the methods defined in WCF (which means I have to implement every request identically in each platform). I'm using my conversion class in WCF to return a model instead of an entity.
It's not the best solution, but it works while I'm waiting for Entity Framework 7.
I usually store my model within a wcf application behind the services layer.
As a result, my model has no dependencies on UI dlls.
Related
Following the instructions to use the Reflection Provider (http://msdn.microsoft.com/en-us/library/dd728281.aspx) everything works well, until I move the classes Order and Item to a Class Library and reference the class library from the web project with the SVC file.
Move the POCO classes into the WCF project all goes well.
Move the POCO classes out of the WCF project into separate assembly, I get a 500 with no explanation.
I want to be able to keep my poco classes in a separate project and expose them with an OData endpoint. What am I doing wrong?
--UPDATE--
The scenario described above is meant to illustrate a problem I have found using the WCF OData Reflection Provider. It is not my real problem, but is easier to explain for illustrative purposes.
Try upgrading to the latest version of WCF Data Services (currently 5.3), if you aren't already on it. I reproduced your issue using the version of WCF Data Services that ships with .Net 4.5, but once I upgraded the references in both assemblies to the latest release of Microsoft.Data.Services using NuGet, the problem went away.
If you're already using the most up-to-date version of WCF Data Services, make sure that both assemblies are referencing the exact same version of WCF Data Services.
If neither of these fix your problem, add the following attribute to your DataService class to get a more detailed error message and stack trace:
[System.ServiceModel.ServiceBehavior(IncludeExceptionDetailInFaults = true)]
public class YourService : DataService<...>
And then please update your question with the results of that (if the solution doesn't immediately jump out from the stack trace).
(disclaimer: I usually don't like answers of the kind that don't help you with your problem but rather explain why your problem isn't the correct problem, but I think it's justified in this case :))
If you think about it, you don't really want to do that:
The Order and Item classes aren't really POCOs at all; they're not 'plain' C# objects; they have data attributes on them, which make them data transfer objects (DTOs).
They belong to the interface between your service and its clients;
The domain entities (or POCOs) Item and Order will, most likely, be a bit more complex, and contain other things besides data, such as operations and business logic.
I believe the correct way to go is to have a rich domain model, in which Order and Item contain a full set of attributes and operations, and on top of that, a DTO layer, which contains only those attributes that your service client needs.
Sending your POCOs over the wire was termed 'the stripper pattern', and I believe it's best avoided.
For a project I'm using Silverlight 4.0 with RIA and EntityFramework 4.0. I have three web projects:
Common.Web: contains general types
Workflow.Web: contains domainservices for workflows
Monitor.Web: contains domainservices for monitors
Both the Workflow.Web and Monitor.Web project uses a Enumeration (SalesChoice) type defined in the Common.Web project as return value on a DomainService.
So far the Web side of this story. We continue with the client part, which consists of two projects:
Workflow.UI: Contains the RIA connection with the Workflow.Web
Monitor.UI: Contains the RIA link with the Monitor.Web
Now my problem (finally :) ). In the Workflow.UI project I need to use information from the Monitor.UI project, so I added a reference between those two. When I build the project I get an error:
Warning as Error: The type 'MyProject.SalesChoice' in 'Generated_Code\Workflow.Web.g.cs' conflicts with the imported type 'MyProject.SalesChoice' in 'Monitor.UI.dll'.
It is pretty easy to explain why it's going wrong, but I'm looking for a solution. Maybe my whole approach with a shared Common.Web project is not possible or the best idea?
(sorry for my bad english)
On this cases I prefer to use a Portable Class Library. Define your enum on that project and add it as reference to all projects where you need it.
Greetings,
We have built an extensive system and data framework api using interfaces and DI. For the data access, if the application is a Windows service/WCF service then a LINQ implementation of the repositories is injected at runtime using Castle. Client web/winform applications use the same Data controllers/domain objects but the implementation portions use injected WCF client classes for data access. The cool part about this setup is that the client and server code can reuse the same domain objects, services and system logic by including the appropriate assembly with a few translations.
I have just now created a Silverlight application using the "Silverlight Navigation Application" template in VS2010. It seems the only way I can reference my desktop CLR code is via linked classes (add existing item/linked). There is not a boat load of plumbing classes, but there are some core classes that handle routing interfaces for emails, SMS messages, logging, and data access using the castle microkernel and application configuration files.
I can do grid displays and whatnot by binding the controls to the WCF service references. However, I would like to reuse the controller model for messaging, data access, logging and so on. I cannot determine if it is worth the time to try to fit all the existing classes into SL project classes or start thinking about somehow creating a new lightweight api for SL? Has anyone had experience with unity/castle and Silverlight?
In regards to "It seems the only way I can reference my desktop CLR code is via linked classes" you could always use a portable class library and it will work on everything from CLR, SL through to Xbox360.
I have a Silverlight Class Library that I want to use in both my Silverlight and my WebService project.
I am able to create and reference the Library in both projects without any problems, but when I try to use any of the classes in the Library on the Silerlight project, I get an ambiguous reference error between my Library and the Asmx Webservice (apparently, the silverlight project believes that the classes in the class library exist in the webservice).
How can I correct this issue? I have tried rebuilding and cleaning, but it does not seem to work. Can anyone help?
Sounds like the objects you are passing to Silverlight, via the WCF service, are the same objects in your class library. In that case the generated web-reference objects will be given the same names. Linking with the library will then give you 2 sets of objects with the same names.
If you install RIA services, once feature is the ability to share code between client and server by simply adding ".shared" in the class filenames before the extensions. ASMX services are so last century :)
if you don't want to learn the RIA services way of sharing objects across the great-web-divide (which I would recommend), you need to separate the data objects from the functionality you actually want to share client and server side.
To give more specific advice on your current set-up I would need to see more about how it is structured.
A technique you can use is aliasing your using statements:
using MyNameSpace = My.Name.Space;
using MyWebService = My.Web.Service;
Then access all of your objects with these aliases to remove the ambiguities.
I'm working on a project where I have 2 web services that need the same entity. The 2 web services are on the same server so on the back-end, they share the same classes.
On the front-end side, my code consumes both web services and sees the entities from both services as separate (in different namespaces) so I can't use the entity across both services.
Does anyone know of a way to allow this to work in .NET 2.0?
I've done this with my entity:
[XmlType(TypeName = "Class1", Namespace = "myNamespace")]
public class Class1
{
public int field;
}
Hoping that my IDE would somehow "know" that the class is the same on both web services so that it wouldn't create separate entities for both classes, but no luck.
Is this possible to do with .NET 2.0 web services?
I think that you can not do that from inside VS but you can manually use the wsdl.exe utility like this:
wsdl.exe /sharetypes http://localhost/MyService1.asmx?wsdl http://localhost/MyService2.asmx?wsdl
Notice the /sharetypes option which turns on the type sharing feature. This feature creates one code file with a single type definition for identical types shared between different services (the namespace, name, and wire signature must be identical).
More info:
Web Services Description Language tool
Framework 2.0 - WebServices Shared Types
I'm not sure about the implementation details with .NET 2.0, but I believe what you want to do is put the common classes in a seperate XSD file and refer to it from within your two WSDL's. This way, the common types have the same namespace between the two services.
Now, how you do this in .NET 2.0 I couldn't give you the specifics on...
Can you check the namespace of the entity? Make sure it is the same in both the web services.