views:

88

answers:

5

Hi,

So I have some class in a business logic .dll. It is not wrapped in a datacontract, I would like to expose it to anything calling the service by doing so in the Service and IService classes (for example). But the only examples I have seen have been to expose classes that are defined in the service, I do not wish to do this and I do not wish to use [Datacontract] in my business logic layer if that makes sense?

Ask if any clarification is required. Help is as always most appreciated.

Thanks :)

edit: I am slightly confused by many of these solutions, what I would like to do is provide the caller of the service a range of classes to instance and then pass back to the service through a method. So:

public Class ServiceConsumer{
    addPerson(){
        theService.addPerson(new theService.Person("Thomas", 22, "Male");
    }
}

Does that make sense? That's a bit pseudo-codish as I can't remember the consumer side of WCF calls off the top of my head. All the solutions seem to require either knowledge of what classes are available or the classes mashed together in one class?

The only other solution I can see so far is to have a method for every class, but let me tell you there will be potentially a hundred classes!

Many thanks.

A: 

For starters, don't annotate the business object with [DataContract]. It's considered bad practice.

About 35 minutes into this video Miguel talks about data contracts.

Scott
To be honest, I'm really hearing a lot of incorrect stuff in that video (from the 35 min mark). For example, that you can't return multiple values without data contracts (you can - `out` parameters), and that you don't want to use a business object as a data contract because it contains more stuff than you want to send over the wire - well then just add a `[DataMember]` to the stuff you want to send, nothing else is sent. Can you please give good reasons why it's considered bad practice?
Allon Guralnek
a) violates SOC (Separations of Concerns)b) You'll definitely run into versioning issues laterc) Keep your domain model clean... to name a few...
larsw
A: 

What you need to use is a Data Transfer Object. It will make sure that there is proper separation between your Business Layer and the Service Layer. Also check this link.

Unmesh Kondolikar
A: 

While you should layer it properly, there are some cases where you dont really need the seperation of UI, Service, and Business Logic. Generally this happens when you are developing a smaller project, and its really not going to grow.

If you choose you still want to do this, see the example below. You are basically going to wrap your types in a Proxy like "RequestContract" In my case my BL types would be MyType and ByMyType. Those two classes are not annotated and they are brought in using DataContracts defined in the service.

public class ExampleService : IExampleService
{
    public ExampleService() { }

    public GetMyTypeResponseContract GetMyType(GetMyTypeRequestContract theType)
    {
        return new GetMyTypeResponseContract()
        {
            MyType = new MyType()
            {
                Response = theType.ByMyType.Request
            }
        };
    }
}

[DataContract]
public class GetMyTypeRequestContract
{
    [DataMember]
    public ByMyType ByMyType { get; set; }
    public GetMyTypeRequestContract() {  }
}
[DataContract]
public class GetMyTypeResponseContract
{
    [DataMember]
    public MyType MyType { get; set; }
    public GetMyTypeResponseContract() {  }
}
Nix
A: 

Have you considered using POCO - http://msdn.microsoft.com/en-us/library/ee705457.aspx

Sajay
A: 

From a technology point of view, you can use a surrogate.

Brian
From a technology point of view - he's correct - but don't.
larsw