none
Datacontract and business object RRS feed

  • Question

  • Hi,

    I have business object for example like this for my ASP.NET MVC website Project.

    public class Customers
    {
        public string ID {get;set;}
        public string Name {get;set;}
    }

    Now, we want to create our own API, so our client can use our service for their business. As we know in WCF we need to create our data contract for our data model.

    Which approach is the best options?

    1. Decorate the existing my business object with data contract?

    2. Keep my business object clean from data contract and create separate class for data model and decorate it with data contract.

    Regards

    Monday, July 7, 2014 7:47 AM

Answers

  • 1. Decorate the existing my business object with data contract?

    Bussiness objects or domain objects are about bussiness rules. The objects can call upon other objects, like objects in a DAL that do CRUD operations with a database.

    2. Keep my business object clean from data contract and create separate class for data model and decorate it with data contract.

    They would be called DTO(s). The DTO(s) would be Datacontratcs in a sperate classlib project called Entites, and the WCF client that should be using the bussiness or domain objects have reference to Entities. The DAL project setting behind the WCF service would have reference to Entities too.

    The WCF client and WCF Service would be passing the DTO(s) between them.

    http://en.wikipedia.org/wiki/Data_transfer_object

    [DataContract]

    public class DtoCustomers
    {

        [DataMember]
       
    public string ID {get;set;}

       [DataMember]
       
    public string Name {get;set;}
    }

    • Marked as answer by wapt49 Tuesday, July 8, 2014 2:30 PM
    Monday, July 7, 2014 1:46 PM
  • I would prefer the second (2) option, i.e. to create new Data Transfer Objects (DTOs) that expose only the properties that they really need to expose. Then you could keep your business logic (properties, methods, etc) in your business objects and keep these classes clean from any code that are specific to WCF.

    You should avoid "polluting" your business objects with any attributes or code that are specific to some framework (WCF, ASP.NET or whatever) whenever you can.

    • Marked as answer by wapt49 Tuesday, July 8, 2014 2:30 PM
    Monday, July 7, 2014 2:23 PM

All replies

  • 1. Decorate the existing my business object with data contract?

    Bussiness objects or domain objects are about bussiness rules. The objects can call upon other objects, like objects in a DAL that do CRUD operations with a database.

    2. Keep my business object clean from data contract and create separate class for data model and decorate it with data contract.

    They would be called DTO(s). The DTO(s) would be Datacontratcs in a sperate classlib project called Entites, and the WCF client that should be using the bussiness or domain objects have reference to Entities. The DAL project setting behind the WCF service would have reference to Entities too.

    The WCF client and WCF Service would be passing the DTO(s) between them.

    http://en.wikipedia.org/wiki/Data_transfer_object

    [DataContract]

    public class DtoCustomers
    {

        [DataMember]
       
    public string ID {get;set;}

       [DataMember]
       
    public string Name {get;set;}
    }

    • Marked as answer by wapt49 Tuesday, July 8, 2014 2:30 PM
    Monday, July 7, 2014 1:46 PM
  • I would prefer the second (2) option, i.e. to create new Data Transfer Objects (DTOs) that expose only the properties that they really need to expose. Then you could keep your business logic (properties, methods, etc) in your business objects and keep these classes clean from any code that are specific to WCF.

    You should avoid "polluting" your business objects with any attributes or code that are specific to some framework (WCF, ASP.NET or whatever) whenever you can.

    • Marked as answer by wapt49 Tuesday, July 8, 2014 2:30 PM
    Monday, July 7, 2014 2:23 PM