Best Data structure to handle one way read only data RRS feed

  • Question

  • Hi, 

    Can somebody tell me what will be optimum data structure for sending data to the client over the WCF service. Considering the fact that data is a read-only information and will move only from Database --> Business layer --> Client and client will use it throughout it's liftime. Please suggest some datastructure, e.g. Data table, array of structs, Dictionary hash table of structs, or collection of custom class or something else. Also it should be optimized for searching as well. 

    I am stuck here. please help

    Thanks and regards,
    Wednesday, June 24, 2009 4:51 AM

All replies

  • Hi

    (imo) the best approach would be to have a plain old code object, ie a custom class
    the fact that the data is readonly doesn't really matter all that much, as wcf takes into account the [DataMember] attributes on your class.
    it's thus possible to have something like

    class Foo{
    public Foo(string someValue){
    _someValue = someValue)
    private string _someValue;

    public String SomeValue {get{return _someValue;}}


    If you need to return lists, return List<YourClass>

    optimized for searching, depends on the fields you're searching on...
    If you only search on one field (an id) consider returning a Dictionary<idtype, yourclass>

    Hope this helps you out

    Please close the thread if your question is answered, and don't forget to rate the best responses!
    Wednesday, June 24, 2009 4:59 AM
  • Hi Frederikm,

    Thanks for your reply.

    According to what you have explained it works something like this - 

    1. When user accesses service, Data is fetched from the database and held in data table.
    2. for each row of data table we have to create and populate object of custom class that you have mentioned above and add it in dictionary.
    3. then return this Dictionary to the client
    don't you think there is slight performance hit here. what if we directly return data table itself?

    Let me know your comment on this.

    Thanks and regards,

    Wednesday, June 24, 2009 5:33 AM
  • Hi

    returning a data table should be possible (I'm not 100% sure if a data table is a data contract or not)..

    However, the issue there is that you're violating SOA principles...
    A datatable is a technology specific object, whereas a normal code object can be consumed by anyone.
    So, a java client will probably have some issues using the contract. 
    Also, clientside you just have a table, not really a notion of what is in there..

    The goal is to make your service contract reusable by other technologies and to allow the implementation (the code that delivers the data to your service)
    to be able to change, without you requiring to update the contract.

    that being said,
    if you own both service and client, and you don't foresee any one else using your service, you might decide to go the data table route..
    but remember that this (at least for me) is a bit of a smelly design..



    Please close the thread if your question is answered, and don't forget to rate the best responses!
    Wednesday, June 24, 2009 7:46 AM
  • hi,

    Yes data table is a data contract. we can send datatable from service to client.

    In my case, i own both service as well as client. but what do you think from the performance point of view?

    Wednesday, June 24, 2009 9:03 AM
  • Hi

    unless you're doing some complex mapping (what I don't think you are) the mapping will not be the performance issue..
    actually, it might be quite good, as the serialized datatable will be much larger than the serialized object

    Also, if you own both client and server use binary encoding if possible :)
    with wcf you can have binary encoding over http transport :)


    Please close the thread if your question is answered, and don't forget to rate the best responses!
    Wednesday, June 24, 2009 11:28 AM
  • Hi,

    Actual reason behind all this communication is, I am looking for optimum way for handling metadata required for an application. This is why I said it will flow in only one direction DB --> Service --> Client. Logic of service will be like

    Service will have one GetMetaData method which accepts ID as parameter and returns some data structure to the client (This is what I have to decide).

    When client calls this method it will not go to the database always. only first time it will fetch metadata for ID provided and will hold it. This Metadata will be returned to the client in some data structure (that has to be decided). If client call this method by providing same ID again then it will simply return the already available metadata. If client provides diff ID then it will check if metadata for provided ID is available or not. if Yes then return it, if no then fetch it from DB hold it and return it.

    Now tell me your thoughts on this.

    Thanks and regards,

    Wednesday, June 24, 2009 12:03 PM
  • hi

    so basically what you need is a generic system to return key value pairs?
    so say that you need to return the following data

    key                                         value
    connectionstring                        someconnectionstring
    retrycount                                 6

    your method signature would be
    public Dictionary<string,string> GetData(int id);

    clientside you could opt to use the raw dictionary, or you could do something like

    class ConfigurationData

    private Dictionary<string, string> _data;

    private Get<T>(string key){...}

    public int RetryCount {
      if(_data.Containskey("retrycount"){return Get<int>("retrycount");}
    return 0;

    service side you have the normal cache options available



    Please close the thread if your question is answered, and don't forget to rate the best responses!
    Wednesday, June 24, 2009 8:59 PM
  • hi,

    Metadata table in database has following structure

    ID FieldName DisplayName DataType DisplayFormat

    There can be many more fields that cannot be displayed here. Hence Dictionary containing only Key, value cannot be good idea. Key here is ID and value should contain information of all other fields that means object of class/struct which is mapped to this table.

    Also you said, service side you have the normal cache options available. I didn't get this point. you mean after fetching data from DB for the first time I should cache it at the service side and should the same whenever next request comes?

    I also observed that you are pointing more towards returning dictionary rather than returning datatable itself. I am still feeling that returning datatable shuold be much easier and faster.

    Thursday, June 25, 2009 4:34 AM
  • Be careful to send only the data that you need through the WCF connection.

    Chances are that a DataTable will also include other informaiton with it, that you may not have control over.  Personally, I would also go the way of an entity class for the datacontract, as you have full control over it, and know exactly what you are sending, and that you only send what you need.
    That said, there's probably not going to be a massive amount of overhead, unless of course you're sending the whole datatable for the sake of one field, then it isn't going to work well at all.

    Also, sending from the database to the business layer is one transmission, and may require mapping, as the data from the database should not, and probably is not the same as that required by the business layer.  It also leads to a very brittle design, as your client is going to be bound to your database, if you generate the datatable in the database layer, then send it to the client.  You might as well miss out the business layer - and simplify the mess in that case!

    I would suggest that the database sends a dto to the business layer, which sends an entity (domain model) to the presentation layer, which uses a presentation model to render in the client.  This way you limit the amount of change necessary when the database changes.  It does incur a little overhead though.

    Hope that helps,


    MCSD, MCTS, MCPD. Please mark my post as helpful if you find the information good!
    Thursday, June 25, 2009 6:05 AM
  • well, if you have multiple fields create something like

    class ConfigData{
    public  int Id {get;}
    public  string FieldName {get;}
    public string DisplayName {get;}

    and the return a dictionary<int, ConfigData> or dictionary<string, ConfigData>, depending if you want to search by id or display name.

    Caching options:
    you can cache on both the client and the service side, if that's what you require (depends on number of clients, etc)
    both will eliminate the need to reload the information from the database and execute the mapping on it..

    As per the previous posts, yes it is a bit more work than just returning the data table, however it is a much robuster design..
    It all boils down to the fact that returning the data type is basically a leaky abstraction.
    A contract, once published (and that is the interface of your service, including the data contracts) should not change.
    If you publish your data table, then I actually depend on your implementation on the database level..
    what if tomorrow you decide to put the configurations in an xml file, or some such..
    the interface will be impacted, however with returning entities, your interface will stay the same, only the service implementation will change.

    To me, a datatable / dataset /.. approach just doens't cut it from a design perspective

    Please close the thread if your question is answered, and don't forget to rate the best responses!
    Thursday, June 25, 2009 6:56 AM
  • Thank you guys for sharing your thoughts with me.

    It will definitely help me design my architecture.

    Friday, June 26, 2009 4:19 AM
  • You can safely return the data table provided that it is the result of a stored procedure or view that hides your physical database attributes.  We were dealing with abstraction and interface versions in databases decades before WCF was a twinkle in anybody's eye.  Sometimes raw performance is the logical choice.

    That said, I think fredikm and Marit Platt have given you some very good advice.

    Joseph w Donahue
    Sunday, June 28, 2009 6:20 AM