Designing Data Transfer Objects RRS feed

  • Question

  • Hi

    In one of the projects, we are using client's DAL framework which requires us to define all properties within DTO as string data type. This means, there are no Enums, no integers, nothing. Does anyne foresee any issues designing DTOs like these? One thing is performance issues due to Boxing/Unboxing in code. The second is additional set of validations we have to write which could have been avoided if modeled correctly. Keeping these aside, does anyone foresee any other issues?

    Is there a way we can do a profiling against DTOs which are all strings versus DTOs modeled correctly to find out memory consumption, ect.

    Any inputs appreciated.

    Wednesday, March 23, 2011 2:17 AM

All replies

  • As well as the removal of the benefits of strong typing....

    I suppose the thing to mention is that your code will take longer to write.

    So it'll presumably cost them more.

    I hope there's a good reason for their approach.

    Wednesday, March 23, 2011 3:30 PM
  • Hi,


    Since you have to use the client provided DAL framework and you do not have any other options there is no need to worry.

    Your domain/UI layers will have some additional work to perform which you can always claim from the client.



    regards, pnvrkprasad
    Saturday, March 26, 2011 5:07 PM
  • Well no matter how you are required to approach it I would create a proxy layer between the rest of your application and their DAL.  I would make the proxy layer stronly typed if possible and make it work the way you would like it to.  Then if you really want to do some performance profiling using CLR Profiler you can show where the issues are and easily swap out the DAL without changing the rest of your application.  You will be amazed at the performance information (memory) that CLR Profiler will give you. 

    Hope this helps,


    Tuesday, March 29, 2011 12:35 PM
  • Just sounds wrong to me but it is a case of risk management. Would I want to worry if the string representing a date is correct for the culture, an int value doesn't have a real part, etc, etc. No I would not. Can serialization be a performance problem, yep it can. Would I prefer to optimize the overridable serialization mechanisms if I prove there is a problem than store everything in strings, yes I would.

    Can you profile it, (as already mentioned) sure, if not CLR Profiler and you have VS then run a Performance Profile. You don't have to be very sophisticated here, grab the clr memory perf counters and write a quick console app to loop over the the DTOs...add a debug.stopwatch and you're set. I would just add that it's work thinking about the serializer to use, there a number of them (including tuned community versions) and it depends how you are consuming the DTOs

    Saturday, April 2, 2011 8:18 AM
  • I agree with the responses from above you will have a drop of performance at the interface because you have the casts, validations and so forth every time you write to the DAL or read from it. 
    Error detection and handling is also a problem because since everything is a string its up to you.

    Memory consuption could also be better if you could use the real types...

    And if you don't write a custom Tool oder AddIn it includes a lot of handwork ;)





    Thursday, April 7, 2011 7:49 AM