Question

I am running into a problem with webservices. My usual approach to development is to create classes like the following.

namespace Project.Entities
{
    public class Entity
    {
        //Some Members        
    }
}
namespace Project.Service
{
    public class EntityService
    {
        public Project.Entities.Entity Get(int EntityID); 
        // More Methods to retrive Entities
    }
}

This works fine for me when the application/website is allowed direct access to the database. I now need to expose the Project.Service methods via a webservice, e.g.

namespace Project.API
{
    public class EntitiyWebService
    {
        [WebMethod()]
        public Project.Entities.Entity Get(int EntityID)
        {
            return new Project.Service.EntityService(EntityID);
        }
    }
}

My problem is that if I call my webservice from another application (which uses Project.Entities) I cannot convert Project.Entities.Entity to Project.API.EntityWebService.Entity. I think I understand why this doesn’t compile, because as far as the compiler is concerned these two classes have nothing in common but their name.

What I really need to know is if I have hit this problem because of bad practises and if I need to start redesigning ASAP, or if I shouldn’t worry about it and just change my references from Entities.Entity to API.EntityWebService.Entity in my app (surely this can’t be the best solution), or how I would go about creating a conversion method since my app and my webservice both use the same DLL, it is only introducing the webservice that the conversion is required. Or if I have the right idea implemented wrongly, or have missed out something. Or none of the above…

I have considered making my webservice just return XML and serialising the results within my app, however this seems like a long winded approach to something there must be a better solution for. Any advice would be much appreciated.

Answer 1

When dealing with web services, we’ve taken the approach of NOT trying to let .net do the regular serialization/deserialization of custom objects.

Instead, we pass everything using JSON. There are standard tools out there that make the serialization/deserialization process pretty smooth. Such as http://json2csharp.com/ and http://json.codeplex.com/

There are several reasons. The first is that by using a standard such as JSON, then pretty much everything out there can consume it. Second, XML is messy… extremely messy. It’s also hard to do right, and very easy to do wrong. Third, we have a MUCH easier time controlling the exact output.

Finally, an interesting note about passing JSON objects is that you can add new fields to it at the provider and change your consumers at a later date. It’s very forgiving.