locked
Smart Client Architecture Services RRS feed

  • Question

  • I have a simple query regarding populating List Controls such as a combo box or list box using services from within a smart client application.

    I'll try and provide an example to explain:

    I have a view that displays data about a Person. Users can update this data. The person data is obtained and persisted using a web service. The Person entity has a number of attributes that are displayed using combo boxes in the view. These values are managed and defined by other views.

    My question is, what is the best way to populate those drop down boxes with the permissible values using a web service approach. When the view is displayed I need to populate the list controls with all permissible values for the list controls.

    For Example:

    Should my Service Contract look something like the following?

    Service Definition

    public IPersonService
    {

        PersonMetaDataResponse GetPersonMetaData() // This method returns all values to populate
                                                                                // list controls.
        Person[] GetPersons() // This method returns all persons.
        UpdatePersonResponse UpdatePerson(Person person) // Updates the person.
    }

    Entities / Messages

    public class Person
    {
        public string Name;
        public DateTime DateOfBirth;
        public string PersonType; // This would be selected from a combo box.
        public string CreditRating; // This would be selected from a combo box.
        public string MemberType; // This would be selected from a combo box.
        other members...
    }

    public class PersonMetaDataResponse
    {
        public string[] PersonType;
        public string[] CreditRatings;
        other members...
    }

    So when the view is first loaded it would make a call to the GetPersonMetaData method to populate
    all the list controls.

    Does this make sense? and has anyone used a similar approach to the above or am I way off here.

    Friday, August 10, 2007 9:30 PM

Answers

  • If you want to return all data as at once you could do so, but if the data is too big the service might time out, from personal experience it has always been better to fill combos separately from a web service and then use caching.

    Secondly, you definitely need to keep your data retrieval methods separate, unless it makes business sense  not to, otherwise you run the risk of having making a lot of changes in your application if a single data structure changes.

     

    Please tell me if you have anything else in mind, or if there are problems with this answer.

    Sunday, August 19, 2007 5:00 PM

All replies

  • Yes, I think that is the way to go.

     

    If it is a high used view and the types rarely change, I would not call it each time the view is opened. This avoids unnecesary load on the servers, decreases bandwidth use and makes the app look more responsive.

     

    My 2 cents.
    Friday, August 10, 2007 10:07 PM
  • I prefer to have the server publish this kind of non-volatile data, and have the client request the volatile stuff. You can read more about how to do publish/subscribe communications on my blog here:

     

    http://udidahan.weblogs.us/category/pubsub/

     

    Hope that helps,

    Sunday, August 12, 2007 9:08 PM
  • I'm sorry but I don't understand where the pub / sub mechanism fits in?

     

    Monday, August 13, 2007 4:49 PM
  • I really don't believe this is a pub/sub situation, what came to my mind is that you implement the webservice as you listed above and have a get method for each combo.

    If the data is not volatile you can take advantage of caching so you don't need to hit your database each time.

    You then set your attributes to refresh the cached data as needed.

    This MSDN article explains how to do it.

    http://support.microsoft.com/kb/318299

     

     

    Tuesday, August 14, 2007 11:45 PM
  • That's what I thought? perhaps I've misunderstood?

    Wednesday, August 15, 2007 8:50 AM
  •  LivetoCodeCodetoLive! wrote:

    I really don't believe this is a pub/sub situation, what came to my mind is that you implement the webservice as you listed above and have a get method for each combo.

    If the data is not volatile you can take advantage of caching so you don't need to hit your database each time.

    You then set your attributes to refresh the cached data as needed.

    This MSDN article explains how to do it.

    http://support.microsoft.com/kb/318299

     

    I really don't recommend having a separate method for each combo. If you have 10 combos, you will end up doing 10 separate web service method calls. Even if you don't hit the database with that form of caching, you will be doing a network call, so I also suggest caching the data at the client.

     

    PS I wonder who is flagging marking these as an anwser.

    Thursday, August 16, 2007 1:15 PM
  •  Freddy Rios wrote:

    I really don't recommend having a separate method for each combo. If you have 10 combos, you will end up doing 10 separate web service method calls. Even if you don't hit the database with that form of caching, you will be doing a network call, so I also suggest caching the data at the client.

    I would agree.  I was going to have a single service call and return all the data in one response.  Caching on the service side could be implement if it was sensible.


     Freddy Rios wrote:

    "PS I wonder who is flagging marking these as an answer"
     

    Good question...

    Thursday, August 16, 2007 4:26 PM
  •  Darren Thomas wrote:

     Freddy Rios wrote:

    I really don't recommend having a separate method for each combo. If you have 10 combos, you will end up doing 10 separate web service method calls. Even if you don't hit the database with that form of caching, you will be doing a network call, so I also suggest caching the data at the client.

    I would agree.  I was going to have a single service call and return all the data in one response.  Caching on the service side could be implement if it was sensible.


     Freddy Rios wrote:

    "PS I wonder who is flagging marking these as an answer"
     

    Good question...

     

    I can understand what Freddy is saying about not making 10 different calls to fill 10 combos, and I understand Darren saying that he can implement it using one call and returning a collection of collections.

     

    My only comment here would be that it should only be done if the business interface can support it , and that you do not go directly to the data layer.

     

    As for flagging as answered, didn't you flag this Darren? I thought it could only be flagged by the guy asking the question.

     

    Secondly, didn't it answer your question? or are there other issues that we haven't addressed?

    Thursday, August 16, 2007 6:06 PM
  •  LivetoCodeCodetoLive! wrote:

    As for flagging as answered, didn't you flag this Darren? I thought it could only be flagged by the guy asking the question.

    I thought so as well.  But I didn't do it.  It doesn't matter.

     

     LivetoCodeCodetoLive! wrote:

    Secondly, didn't it answer your question? or are there other issues that we haven't addressed?

    Sort of, and all the input is appreciated.  But I was hoping for a more definitive answer.  I can't believe that
    I'm the only person doing this sort of thing?

     

    Thursday, August 16, 2007 6:31 PM
  • If you want to return all data as at once you could do so, but if the data is too big the service might time out, from personal experience it has always been better to fill combos separately from a web service and then use caching.

    Secondly, you definitely need to keep your data retrieval methods separate, unless it makes business sense  not to, otherwise you run the risk of having making a lot of changes in your application if a single data structure changes.

     

    Please tell me if you have anything else in mind, or if there are problems with this answer.

    Sunday, August 19, 2007 5:00 PM
  •  Udi Dahan The Software Simplist wrote:

    I prefer to have the server publish this kind of non-volatile data, and have the client request the volatile stuff. You can read more about how to do publish/subscribe communications on my blog here:

     

    http://udidahan.weblogs.us/category/pubsub/

     

    Hope that helps,

     

    Apologies, I now see how this could be done.  I think what you are saying is that the owning service would periodically publish the reference data with a version.

     

    A client could then cache this information until the next publication.

    Wednesday, August 22, 2007 2:44 PM
  •  LivetoCodeCodetoLive! wrote:

    If you want to return all data as at once you could do so, but if the data is too big the service might time out, from personal experience it has always been better to fill combos separately from a web service and then use caching.

    Secondly, you definitely need to keep your data retrieval methods separate, unless it makes business sense  not to, otherwise you run the risk of having making a lot of changes in your application if a single data structure changes.

     

    Please tell me if you have anything else in mind, or if there are problems with this answer.

     

    I agree on having separate method calls if the data is too big. I suggested a single method plus caching, since Darren's example on the information was pretty simple meta-data. The primary issue I have faced on geographically distributed scenarios, is loading time is greater when doing separate method calls. Do you think it can be alleviated by using asyncronous calls to invoke 5-10 web service methods?

     

    When you say you need to keep data retrieval methods separate, you mean at the internal service implementation, right?
    Wednesday, August 22, 2007 3:29 PM
  • The main advantage of this approach is its efficiency - especially when dealing with many clients. If you use a transport that does this well (like UDP Multicast) you can communicate the data you need to all clients with one network hop. That's scalability at its best.

     

    I also try to keep my application code at the pub/sub level even if I'm not using a pub/sub enabled transport. This is still more efficient than having each client poll (possibly multiple times per version) since it involves one network hop per client, per version.

     

    This is one of the main reasons why I've developed NServiceBus [http://www.NServiceBus.com].

     

    Take a look and let me know if you have any questions.

    Monday, August 27, 2007 3:55 PM