none
Business entities or service data contract? RRS feed

  • Question

  • Hi everybody;

    I’d like to know what’s best practice for you.

    I have a distributed app as follows:

    DATA REPOSITORY (SQL)
    DATA ACCESS LAYER

    BUSINESS ENTITIES
    BUSINESS LOGIC LAYER

    SERVICE ENTITIES (DATA CONTRACT)
    SERVICES

    CLIENT


    Currently I have a business entities layer that is handled by the business layer.
    The business layer is called from the service layer, and usually when a business layer function is invoked, a business entity is returned, like a customer collection.

    Once the service layer gets the entity object, it converts that object to a similar representation of it, which is contained in the service entities layers (or the service data contract).

    For example, a business entity object named customer is converted to a service entity layer object named customer that has all the serialization information include it on it.

    In the old days, I would by-pass the service entities layer, and I would serialize the business entities layer objects directly down the wire, but by example, with WCF i learned that is better to convert all complex objects returned from the business layer into a less complicated structure.

    My question is what you would do:

    a)      Serialize/de-serialize directly objects from the Business Entity layer.

    b)      Or have a separated data contract at the service level, which ultimately will be the one traveling down the wire?

     

    Tuesday, February 19, 2008 9:19 PM

Answers

  •  

    The consideration really is, are the entities the same as what the service contract specifies, in a lot on instances they are not.  It would also make a service coupled to the entities from the client right through the services, and business layer.

     

    Here there's clearly a trade-off - one of of speed versus de-coupled designs.  What are your QoS requirements (non-functionals) for the service layer?  It performance a major issue?

     

    I'd say that if performance isn't of utmost importance, that you'd have a much cleaner implementation using a data contract specified by the service, that travels down the wire, and that there is some sort of translation before that, maybe even something that is pluggable, to allow that transformation to change without requiring a complete re-compilation?  We're really talking about something similar to LINQ but for the service contract, aren't we?

     

    The ideal really with services, is to decouple them as much as you can which is why I would choose b).  I'd imagine that the overhead of the translation step wouldn't be that noticeable in your system anyway.  If you have a lot of data being returned, then it becomes more noticeable, but then you'd have to question the design, the fact that so much data is required.  If you design up front for this situation I think you can get the best of both worlds with option b).  Option A is limiting by nature, yes might be a little quicker, but if it's almost unnoticeable, then that would be a bad design choice?

     

    What did you think?

     

    Martin Platt.

    Tuesday, February 19, 2008 11:32 PM
  • It seems as though you're abstracting the business entities from the service contract, so that any changes to the entities will not impact the service contract. If that is a necessary business requirement, the latter option is preferable.
    Tuesday, February 19, 2008 11:33 PM

All replies

  •  

    The consideration really is, are the entities the same as what the service contract specifies, in a lot on instances they are not.  It would also make a service coupled to the entities from the client right through the services, and business layer.

     

    Here there's clearly a trade-off - one of of speed versus de-coupled designs.  What are your QoS requirements (non-functionals) for the service layer?  It performance a major issue?

     

    I'd say that if performance isn't of utmost importance, that you'd have a much cleaner implementation using a data contract specified by the service, that travels down the wire, and that there is some sort of translation before that, maybe even something that is pluggable, to allow that transformation to change without requiring a complete re-compilation?  We're really talking about something similar to LINQ but for the service contract, aren't we?

     

    The ideal really with services, is to decouple them as much as you can which is why I would choose b).  I'd imagine that the overhead of the translation step wouldn't be that noticeable in your system anyway.  If you have a lot of data being returned, then it becomes more noticeable, but then you'd have to question the design, the fact that so much data is required.  If you design up front for this situation I think you can get the best of both worlds with option b).  Option A is limiting by nature, yes might be a little quicker, but if it's almost unnoticeable, then that would be a bad design choice?

     

    What did you think?

     

    Martin Platt.

    Tuesday, February 19, 2008 11:32 PM
  • It seems as though you're abstracting the business entities from the service contract, so that any changes to the entities will not impact the service contract. If that is a necessary business requirement, the latter option is preferable.
    Tuesday, February 19, 2008 11:33 PM
  • Thanks for the responses.

    Although it is not a requirement is seems like a better design choice to me.

     

    Wednesday, February 20, 2008 5:11 AM
  • Hi Pepehammer.

    I finally ended up with the same seperation as you mention. I also started out with bypassing the servicelayer completely, but since the buisness entities changed frequently and I had no control of this, I found that the best solution (in my case) is to seperate buisness entities and datacontracts.

    But my next question is then; how do you translate buisnessentities to datacontracts? Do you do this manually, or is there a smart way to do this? I read something about an entitytranslator in WSSF  - Web Service Software factory http://msdn.microsoft.com/en-us/library/ff647889.aspx. Have you tried this?

    Monday, July 12, 2010 1:30 PM
  • Some time abstration is a over kill. For example in this case, if we maintin different types for business entites and service data contracts, there is unnecessary (value addition is really questionable) overhead.

    for example, if business entity/type changes, you would want to change the service data contract also, otherwise, there is no use fo changing only business type.

    with ADO.NET Entity Model, we alredy have model entites/types.

    then more or less the same way, we will have business entites

    then more or less way, we will have data contracts in the same way.

    so there are 3 transformations required... so for medium sized projects, i would suggest that, you can define a common types and use them as: Service Data Contracts and as well as Business Entites. This way, Business Logic can fetch data from model entities, and fill the common types (used as Business Entites and aswell as service data contracts) and return them to Service operation, which inturn returns to client.

    Hope I did not add more confusion... 


    Venkat
    Monday, September 12, 2011 9:08 AM