I have a Silverlight solution that references a third-party web service. This web service generates XML, which is then processed into objects for use in Silverlight binding. At one point we the processing of XML to objects was done client-side, but we ran into performance issues and decided to move this processing to the proxies in the hosting web project to improve performance (which it did). This is obviously a gross over-simplification, but should work. My basic project structure looks like this.
Solution
Solution.Web - Holds the web page
that hosts Silverlight as well as
proxies that access web services and
processes as required and obviously
the references to those web
services).
Solution.Infrastructure - Holds
references to the proxy web services
in the .Web project, all genned code
from serialized objects from those
proxies and code around those objects
that need to be client-side.
Solution.Book - The particular
project that uses the objects in
question after processed down into
Infrastructure.
I've defined the following Interface and Class in the Web project. They represent the type of objects that the XML from the original third-party gets transformed into and since this is the only project in the Silverlight app that is actually server-side, that was the place to define and use them.
//Doesn't get much simpler than this.
public interface INavigable
{
string Description { get; set; }
}
//Very simple class too
public class IndexEntry : INavigable
{
public List<IndexCM> CMItems { get; set; }
public string CPTCode { get; set; }
public string DefinitionOfAbbreviations { get; set; }
public string Description { get; set; }
public string EtiologyCode { get; set; }
public bool HighScore { get; set; }
public IndexToTabularCommandArguments IndexToTabularCommandArgument { get; set; }
public bool IsExpanded { get; set; }
public string ManifestationCode { get; set; }
public string MorphologyCode { get; set; }
public List<TextItem> NonEssentialModifiersAndQualifyingText { get; set; }
public string OtherItalics { get; set; }
public IndexEntry Parent { get; set; }
public int Score { get; set; }
public string SeeAlsoReference { get; set; }
public string SeeReference { get; set; }
public List<IndexEntry> SubEntries { get; set; }
public int Words { get; set; }
}
Again; both of these items are defined in the Web project. Notice that IndexEntry implments INavigable. When the code for IndexEntry is auto-genned in the Infrastructure project, the definition of the class does not include the implmentation of INavigable. After discovering this, I thought "no problem, I'll create another partial class file reiterating the implmentation". Unfortunately (I'm guessing because it isn't being serialized), that interface isn't recognized in the Infrastructure project, so I can't simply do that. Here's where it gets really weird. The BOOK project CAN see the INavigable interface. In fact I use it in Book, though Book has no reference to the Web Service in the Web project where the thing is define, though Infrastructure does. Just as a test, I linked to the INavigable source file from indside the Infrastructure project. That allowed me to reference it in that project and compile, but causes havoc in the Book project, because now there's a conflick between the one define in Infrastructure and the one defined in the Web project's web service. This is behavior I would expect.
So, to try and sum up a bit. Web project has a web service that process data from a third-party service and has a class and interface defined in it. The class implements the interface. The Infrastructure project references the web service in the Web Project and the Book project references the Infrastructure project. The implmentation of the interface in the class does NOT serialize down, so the auto-genned code in INfrastructure does not show this relationship, breaking code further down-stream. The Book project, whihc is further down-stream CAN see the interface as defined in the Web Project, even though its only reference is through the Infrastructure project; whihc CAN'T see it.
Am I simple missing something easy here? Can I apply an attribute to either the Interface definition or to the its implmentation in the class to ensure its visibility downstream? Anything else I can do here?
I know this is a bit convoluted and anyone still with me here, thanks for your patience and any advice you might have.
Cheers,
Steve
Related
I have a C# Web API project which has a Product class:
public class Product
{
public int Id { get; set; }
public string Name { get; set; }
public string Category { get; set; }
public decimal Price { get; set; }
}
and the following method to get a Product by it's Id:
public Product GetProduct(int id)
{
Product item = repository.Get(id);
if (item == null)
{
throw new HttpResponseException(HttpStatusCode.NotFound);
}
return item;
}
Say I now have 10 different C# projects (i.e. not in the same solution, and a mixture of Windows Forms, Console, MVC etc) that all want to call this method and get a Product. I want to reduce the need for all 10 separate projects to have to have a class file for a Product object which is just duplicating the same structure, and also avoid using a class library DLL that is added to each project, is this possible somehow?
I know when I've previously used web services in .NET (these were the original services that created a WSDL file, and also WCF services), Visual Studio (I think) automatically created these classes behind the scenes based on the WSDL information which meant you could just consume a service and not have to worry about hand crafting each object yourself.
Is this possible to do in a Web API environment?
I'm designing a composite WPF/MVVM application using Prism patterns. I've read the Developer's Guide to Microsoft Prism Library 5.0 for WPF and I am familiar with most of the patterns described.
My application's modules will consist of a number of binaries (dll-s) and some of them will include a shared library, which will define public interfaces to MVVM models, event classes for event aggregator and services implemented by that module. Other modules would be able to reference such a library and work with its models, events and services through public interfaces and IoC.
Let's say ModuleA.Shared shared library includes a public interface for its SampleModel and SampleService, which performs work with SampleModel:
namespace ModuleA.Shared
{
interface ISampleModel
{
int SampleProp01 { get; set; }
int SampleProp02 { get; set; }
}
interface ISampleService
{
ISampleModel GetSampleModelInstance();
void SaveSampleModelInstance(ISampleModel obj);
}
}
Now say ModuleB (in a non-shared binary) uses ModuleA's public library:
namespace ModuleB.Engine
{
class SampleClass
{
void SampleMethod()
{
ModuleA.Shared.ISampleService srvc = SomeIoCContainer.Resolve<ModuleA.Shared.ISampleService>();
ModuleA.Shared.ISampleModel obj = srvc.GetSampleModelInstance();
// Do some work on obj...
srvc.SaveSampleModelInstance(obj);
}
}
}
Okay, now let's say ModuleB is developed and mantained by a third-party (like a third-party plugin). At some point in time I add a new property to ModuleA.Shared.ISampleModel:
namespace ModuleA.Shared
{
interface ISampleModel
{
int SampleProp01 { get; set; }
int SampleProp02 { get; set; }
int NewProp { get; set; } // <-- New property
}
/* ... */
}
The final user upgrades my application, so the old ModuleA's binaries get replaced with the new ones. ModuleB is distributed by a third-party and its binaries stay the same.
Since ModuleA and ModuleB are now compiled with different versions of ModuleA.Shared.ISampleModel, I assume IoC resolving will not succeed and the application will end in an exception.
What I am asking is what are the good practices / patterns for resolving this kind of issuses? How to make some modules upgradable without breaking the support for third-party modules which depend on them and were built with an older version of their shared libraries?
This is completely independent of whether you use prism or not. You're providing a plugin api (through the use of prism's module disconvery), and you have to plan for versioning your api.
First of all, once a version of the api is released, it's frozen. You cannot ever touch it (unless you want your third parties to recompile everything, making them and your customers unhappy, to say the least).
Instead of changing the api, release a new version of it:
interface ISampleModelV1
{
int SampleProp01 { get; set; }
int SampleProp02 { get; set; }
}
becomes
interface ISampleModelV2
{
int SampleProp01 { get; set; }
int SampleProp02 { get; set; }
int NewProp { get; set; } // <-- New property
}
A third party can then decide to either continue to use ISampleModelV1 or switch to ISampleModelV2 if they need NewProp. Your app, of course, will have to support both of them.
As this gets ugly sooner or later as the amount of api versions increases, you might want to deprecate the old ones, e.g. if your app goes from 2.5 to 3.0, you could remove support for api 1.x... be sure to communicate these decisions to customers and third parties early enough, though.
BTW:
Challenges Not Addressed by Prism
[...] Application versioning
I've added an existing method to a web service (that I did not write).
I can bring the method into Soap UI by performing and update on the service.
I can run the method in SOAP UI and debug it and clearly see my method is pulling the data I want, processing it correctly but I am getting nothing back in Soap UI and my debugger terminates at that point.
Its worth nothing I build this method from an existing working method that returns data just fine. I imagine I am just missing some minor configuration some ware.
Things I have done,
1) Added the new method to the operation contract
2) Added all the necessary logic for processing the data.
I can furnish any code/configs but I just don't know what exactly is needed to troubleshoot this as I am attempting to add this off existing code. I'm generally not a vague with the details but I'm in the process of educating myself at the same time as well as trudging through some existing documentation I have found online.
The service is intended to return a class. We define a DTO and paste the results from a SQL query into our DTO. We then do some integrity checking on the DTO and test for failure or success. We then add the DTO to a container object named CustomResult based on success or failure and return the CustomResult. The CustomResult class should not need any modifying (famous last words). I did however create a new DTO class which I can add to my original post
DTO Class
namespace Custom.Company.Services
{
[DataContract]
public class TimeUnitDto
{
[DataMember]
public string Calendar { get; set; }
[DataMember]
public long AverageHour { get; set; }
[DataMember]
public long AverageDay { get; set; }
[DataMember]
public long AverageWeek { get; set; }
[DataMember]
public long AverageMonth { get; set; }
[DataMember]
public long AverageYear { get; set; }
[DataMember]
public long LookupRefreshInd { get; set; }
}
}
Thanks,
All, I figured it out. Unfortunately the answer is propriety to what I am doing but basically we the DTO to our CustomResult Class.
I copy/pasted the code from another service we use since the functionality was similar. I forgot to replace of the 'Status' assignments to the new status I created for this dto.
It was trying to place it in a Status object that the data is not going to recognize. Thanks to everyone who looked into this for me.
I got an Employee class and each employee has a list of applied leaves. Is it possible to have the list AppliedLeave as a [DataMember] in WCF?
[DataContract]
public class Employee
{
[DataMember]
public string UserID { get; set; }
[DataMember]
public int EmployeeNumber { get; set; }
[ForeignKey("EmployeeUserID")]
[DataMember]
public List<Leave> AppliedLeave
{
get { return _appliedLeaves; }
set { _appliedLeaves = value; }
}
private List<Leave> _appliedLeaves = new List<Leave>();
...
}
Is there any other way to do this?
thank you for your consideration of this matter
I extend my Question
This is my Leave Class:
[DataContract]
public class Leave
{
[Key()]
[DataMember]
public Guid LeaveId { get; set; }
[DataMember]
public string LeaveType { get; set; }
[DataMember]
public DateTime StartDate { get; set; }
[DataMember]
public string EmployeeUserID { get; set; }
}
this shows ServiceContract ---->
[ServiceContract]
public interface IEmployeeService
{
[OperationContract]
Employee GetEmployeeByUserId(string userId);
[OperationContract]
void AssignSupervisor(string userId, string supervisorUserId);
[OperationContract]
void DeleteEmployeeByUserId(string userId);
....
}
In Client application,
EmployeeServiceClient employeeService = new EmployeeServiceClient();
Employee employee = employeeService.GetEmployeeByUserId(id);
But when Employee gathered from the service its shows Null for leaves,
Can somebody help me? what have I done wrong here?
Yes, it is possible to return generics from WCF service operations.
But by default they are casted to Array on client side. This can be customized while proxy generation.
WCF: Serialization and Generics
Also you have to decorate the service with all the types to which generics can be resolved, using KnownTypeAttribute.
Known Types and the Generic Resolver
I also found my server side list would always arrive at the client as a null pointer. After browsing around a lot for this problem it strikes me it is nearly always denied at first ("your code should work")
Found the issue.. I had configured my solution using one "WCF Service" project and one "Winforms app" project with a generated service reference. Both interface and implementation of Service1 were in the WCF service project, as expected. But any list member returned null.
When I put my IService1.cs = the interface only = in a separate class library instead, reference the class library on both sides (using) and generate the service reference again, my list does work ! The generated code on the client side looks much simpler.
I did not need any special attributes, change service reference configuration, or interface references for this.
You could use IList<T> instead of List<T>.
So I am working with WCF and my services return types that contain generic lists. WCF is currently converting these to arrays over the wire. Is there a way I configure WCF to convert them back to lists afterwards? I know there is a way by clicking advanced when you add a service reference but I am looking for a solution in configuration files or something similar.
[DataContract(IsReference = true)]
public class SampleObject
{
[DataMember]
public long ID { get; private set; }
[DataMember]
public ICollection<AnotherObject> Objects { get; set; }
}
It is very odd, also, because one service returns it as a list and the other as an array and I am pretty sure they are configured identically.
At the advanced tab when adding your service reference you can set this option as well. standard Arrays are set.
I think this is dent with purely from the way that the client tool generates the contracts from the WSDL. In my case, I made a reusable .dll that contains my [OperationContract] and [DataContract] classes, and use it from both the client and the server, instead of generating one with SvcUtil. This way I preserve my lists of generics.
In addition, take care not to have both arrays and generics in the classes from which you serialize the instances with WCF, because you'll get a problem during deserialization : everything will be converted either to ArrayOf (if you don't change the configuration) or to Collection Type.
As result you will get errors during deserialization from the WCF code trying to assign an array where you wait a Collection and conversely.
This was just my 2cent advice from what I learned during a small project with WCF. :)
I found a solution that was much simpler and worked well enough for me, although it might not work for others. I simply switched from using ICollection (IList also produces this result) to List. It worked fine after that.
Solution from Here.
I also found a possible configuration solution from Here near the bottom.
<CollectionMappings>
<CollectionMapping TypeName="ChangeTracker.ChangeTrackingCollection'1" Category="List" />
</CollectionMappings>
Instead of use ICollection<AnotherObject> in your data contract, that will be generated in client application as a AnotherObject[].
Try this:
define a new data contract
[CollectionDataContract]
public class AnotherObjectCollection : List<AnotherObject> {}
in your code:
DataContract(IsReference = true)]
public class SampleObject
{
[DataMember]
public long ID { get; private set; }
[DataMember]
public AnotherObjectCollection Objects { get; set; }
}
in Visual Studio (same to svcUtil), the client proxy code will appear like this:
[System.Diagnostics.DebuggerStepThroughAttribute()]
[System.CodeDom.Compiler.GeneratedCodeAttribute("System.Runtime.Serialization", "3.0.0.0")]
[System.Runtime.Serialization.CollectionDataContractAttribute(Name="AnotherObjectCollection", Namespace="http://schemas.datacontract.org/2004/07/SampleObject", ItemName="AnotherObject")]
[System.SerializableAttribute()]
public class AnotherObjectCollection : System.Collections.Generic.List<AnotherObject> {}
DataContract(IsReference = true)]
public class SampleObject
{
[DataMember]
public long ID { get; private set; }
[DataMember]
public AnotherObjectCollection Objects { get; set; }
}
This also works for built-in .NET types.
antonio