locked
Business entities[objects] Vs Service entities[objects] RRS feed

  • Question

  • ever since I posted the reference architecture for enterprise using 3.5 framework, I have been running this at the back of my mind...

     

    Service Entities[objects]/DTO

    Are objects used as datacontracts (like Person is a new or returning customer) to transfer information across different layers, like business objects to user experience, in a n-tier application...

     

    Business Entities[objects]

    Are your application model objects, like Patient, Doctor, Pharmacist, etc.,

     

    So my question, it looks like most of the time Service entities are subset[property, method or composite] of Business entities.

     

    Other than considering the fact to keep the network calls small, what is the purpose of creating a separate service objects.

     

    Would appreciate any feedback from community.

    Friday, May 2, 2008 2:18 AM

Answers

  • Hi

     

    to me

    - a DTO is just a data contract , a Business Entity is an "intelligent" object, that has a number of methods/properties with which you can interact.

    - a DTO can have different versions existing at one time, ideally with just one Business Entity.
    eg  http://company.com/types/customer/2008/02 and http://company.com/types/customer/2008/03 both point to the Customer Business Entity.

    I normally give my Business Entity a constructor taking a DTO.

    - encapsulation

    if you expose your business entity, any change breaks the clients. seperate implementation and data contract Smile

     

    Hope this helps you out

    Friday, May 2, 2008 9:43 PM

All replies

  • The CLSA frameworks argues that there isn't a need to separate the two, arguing that once you serialize a BizObject then you've got a DTO. I would argue that a DTO is akin to your Biz protocol, i.e. how should I talk to your services? The key point for me is that the DTO should be platform/implementation agnostic, e.g a simple XML based DTO can be called via REST, serialization, etc and from any platform. However, if you know your solution will be constrained in a Microsoft platform and you'll only be communicating via .net then it's quite compelling to avoid the DTOs.

    Friday, May 2, 2008 6:14 AM
  • Hi

     

    to me

    - a DTO is just a data contract , a Business Entity is an "intelligent" object, that has a number of methods/properties with which you can interact.

    - a DTO can have different versions existing at one time, ideally with just one Business Entity.
    eg  http://company.com/types/customer/2008/02 and http://company.com/types/customer/2008/03 both point to the Customer Business Entity.

    I normally give my Business Entity a constructor taking a DTO.

    - encapsulation

    if you expose your business entity, any change breaks the clients. seperate implementation and data contract Smile

     

    Hope this helps you out

    Friday, May 2, 2008 9:43 PM