Where should I put Comparers in an application using WCF?
I have an application that uses WCF for all DataAccess. It returns some business objects and has some operations.
Should this code exist in my Client or my service? If in a service, HOW should I implement it? Can I just add it as an interface to my business object? Will this go through the WCF service proxy?
(This is a sample from MSDN, I would like some feedback before I implement my own, but it will be 99% the same)
// Custom comparer for the Product class.
class ProductComparer : IEqualityComparer<Product>
{
// Products are equal if their names and product numbers are equal.
public bool Equals(Product x, Product y)
{
// Check whether the compared objects reference the same data.
if (Object.ReferenceEquals(x, y)) return true;
// Check whether any of the compared objects is null.
if (Object.ReferenceEquals(x, null) || Object.ReferenceEquals(y, null))
return false;
// Check whether the products' properties are equal.
return x.Code == y.Code && x.Name == y.Name;
}
// If Equals() returns true for a pair of objects,
// GetHashCode must return the same value for these objects.
public int GetHashCode(Product product)
{
// Check whether the object is null.
if (Object.ReferenceEquals(product, null)) return 0;
// Get the hash code for the Name field if it is not null.
int hashProductName = product.Name == null ? 0 : product.Name.GetHashCode();
// Get the hash code for the Code field.
int hashProductCode = product.Code.GetHashCode();
// Calculate the hash code for the product.
return hashProductName ^ hashProductCode;
}
}
source to share
Remember, data sent over WCF (or over any SOAP based service) is messages. They don't have any behavior (it won't be interoperable), so all your nice behavior will be lost in translation.
This means that you really only have one option: your business logic must be in the service, as it cannot be on the client.
However, there are several ways to share code between the service and the client, but unless you are using WCF solely as a message stack, it is not recommended, as it will bind the client and service together and close it is impossible to change the two independently (let alone encouraging new customers to use this service).
source to share
Well, proxies created by WCF are classes partial
, so you can add behavior on the client even if you are using the mex generation.
You can also use assembly sharing ( /reference
on the command line or check boxes in the IDE) - then you can use the same type on the client and server, but it violates most of the rules of "pure" SOA.
It depends on how you think "clean" you feel. The pain of cleanliness, but to maintain two identical code bases, may outweigh the convenience but mess of assembly sharing. It depends on what the application is. I have enjoyed using share sharing on a number of occasions and I feel no guilt; it was the smartest option for the script.
Just remember that client code is convenient - always treat the client as hostile, so even if your client is using assembly sharing, remember that a hostile client cannot, so it won't follow your rules; always check on the server.
source to share