2

I am building a WCF service.

The Data Contract objects will be the exact same as the Business Objects.

Should I create Data Contracts in my WCF service or reference my BO Layer and use those Business Objects in my WCF Operations?

Gadam
  • 2,674
  • 8
  • 37
  • 56

3 Answers3

4

I would split them in different projects:

  • Foo.DataContracts
  • Foo.BusinessModels
  • Foo.Services

Reference BusinessModels and DataContracts in Services. Then map the model classes to contract classes using AutoMapper and vice versa. You can then later change your models without breaking your WCF clients, since they rely on the contracts.

funeralfunk
  • 163
  • 10
  • Sorry if I haven't given the full picutre: I already have an existing application/Solution with:Business Layer(project), Data Layer(project) and the Presentation Layer(WebSite). – Gadam Mar 22 '13 at 18:45
  • Ok, so create another project (Services) for your WCF. You can then reference your Business Layer project for the models. If you don't want to create a separate project for the data contracts, add them in the new Services project. Map models<->contracts. – funeralfunk Mar 22 '13 at 18:57
  • Thanks that kind of answers my question Here's the remaining doubt: Why do I have to define the Data Contracts at all? Since I have the reference to the BL in my service, can't I directly work with those (BO) objects instead? (Because they would be exactly the same, even the names). Also, I am just talking about a few objects for now so I dont want to learn about the AutoMapper. Can you tell me if I need to create a new class file inside my Services project and have a method that maps Contracts <--> BO property by property? is that it? Thanks again – Gadam Mar 22 '13 at 19:35
  • 1
    You can, but what happens when you decide to change your BO implementation? You will make a breaking change in your WCF and your clients will not be able to use it. The point of data contracts is to avoid that. I understand that your objects are identical right now, but you should design your architecture to work long-term. – funeralfunk Mar 22 '13 at 20:00
0

If your business objects can be serialized without muddling the concerns of serialization in with the business logic, then I'd say go for it.

A better alternative though is to bring your business logic layer behind the Services layer and expose simple DTOs from the service that your view can bind to.

I wrote an article on this approach with WCF RIA Services that translates pretty well to standard WCF Web Services

Michael Brown
  • 9,041
  • 1
  • 28
  • 37
  • Thanks, will look at your article. What do you mean by 'bringing' the BL behind the SL -- I am assuming you mean to Create Data Contracts and map them to BO...? – Gadam Mar 22 '13 at 19:49
0

I think in the same line of @valpolushkin though I have not used AutoMapper till now.

See my answer in WCF Message & Data Contract, DTO, domain model, and shared assemblies for an example where the use of Business Entities as Data Contract can cause breaking changes.

I think, it is a very bad practice to use Business Objects as DataContracts. The Service need to be autonomous. The service may be used by clients that has / has not got Lax Versioning.

Refer Service Versioning.

It is easy to mistakenly believe that adding a new member will not break existing clients. If you are unsure that all clients can handle lax versioning, the recommendation is to use the strict versioning guidelines and treat data contracts as immutable.

Also, refer MSDN - Service Layer Guidelines

Design transformation objects that translate between business entities and data contracts.

Community
  • 1
  • 1
LCJ
  • 22,196
  • 67
  • 260
  • 418