Multi-Level Editable Data Structure

Multi-Level Editable Data Structure

Old forum URL: forums.lhotka.net/forums/t/820.aspx


Chaim posted on Friday, August 04, 2006

I’m having a situation where I am dealing with a Multi-Level object where I need to display all level at once - on one screen where mostly the main data entry will happen on the lower levels:

 

Following is an example of objects:

 

  1. MerchantList – needed to keep the list & to get it from the DB
  2. Merchant – needed so we can display derived info in proper context
  3. FacilityList -
  4. Facility – will have a couple of editable fields
  5. EmployeeList – will be able to add new employees
  6. Employee –

 

So I’m trying to come up with the right way to structure the objects and how to retrieve them from the database.

 

Currently I think I’ll have 3 stored procedures each will bring me 2 levels while calling the subsequent Procedures with the Id’s of its parents, like

 

GetMerchantList()

            Returns a list of Merchants, therefore I’ve data to populate: 1. MerchantList 2. Merchant

            Then GetMerchantList (c#) will call GetFacilityList(MerchantID) to get the next 2 levels… and so on.

 

I would be more comfortable knowing if this is the right way, and if this example has been discussed in the book (which I might have overlooked) .

 

Thanks

Chaim

Chaim replied on Friday, August 04, 2006

I would greatly appreciate if someone could please comment.

RockfordLhotka replied on Friday, August 04, 2006

I'm afraid you haven't provided enough information to give good advice.

You have one screen with one OK button? So the user can add data about the merchant's facilities, add and edit some employees and then click either Cancel or OK to abandon or commit everything?

Or, when the user edits a facility it commits, and when they add an employee it commits?

Basically, you've provided an overview of your data relationships, but no context in terms of use cases, user scenarios and required behaviors - which is really the important part of the analysis and design process.

Chaim replied on Sunday, August 06, 2006

O' Rocky thanks for replying, and for your beautiful product in general.

I'll be using the information to display it in a master detail type of grid ( 3 to 4 levels).

so my question is;

   1. how do i structure the objects?

   2. how should it get the data from the database?

so in my illustration above I've set up a few parent & children objects so its true the one line of code will cause the whole structure to get the data populated but in the end result it will require multiple round trips to be made to the database.

the first stored procedure a list of all the merchants.(this stored procedure cannot return the facility list, since I'll need to distinguish to which merchant it is related).

then for each merchant it will call the second stored procedure which will get all the facilities for each merchant ( then the same thing will happen for the Employee list....)

I'm just not sure if this is the right way of doing it so I'm asking for your advice.

Thanks (please ask for clarification if needed)

RockfordLhotka replied on Monday, August 07, 2006

What you are trying to do is not unlike the issues involved when loading grandchild objects. This has been discussed numerous times, most recently here

http://forums.lhotka.net/forums/thread/1974.aspx

There is not an example like this in the book, no. And I doubt very much that you'll be able to get all your data from one stored procedure call - but that'd be true with a DataSet or any other type of object...

Copyright (c) Marimer LLC