How to populate UI without breaking n-tier paradigm

huambo · December 29th, 2011, 03:57 PM

Greetings,

I am modeling my app based on your methodology where we have the 3 layers.

Say that I have a Visit table, a dal visit, a bo visit, and a bll visit class.

My table looks like:

Visit (visitid, visitdate, visittime, visitStatusCode, visitCategoryCode, etc)

My bo.Visit has the same properties as the visit table above.

The dilemma is this: on the ui, i need to display a grid showing all the visits but, instead of showing the internal codes for visits status and visit category. I want to display the descriptions: visit status description and category description.

In the past, i added cached datasets and an item template using a function to translate the code to the description on the row bound event.

This seems expensive and also breaks all the n-tier philosophy.

I could also create a FAT object with all the properties I would consume on the UI by getting all the properties in the dal into my business object. My concern is that for each visit that I load, I will have to make 2 more calls to get the visit status and category descriptions.

Or, use a view or proc with all the properties i need and on the dal.getAll() populate the FAT object?

Please advise,
huambo

happy new year

Imar · December 30th, 2011, 06:53 AM

Hi there,

As suggested earlier, you could create a Category object (or some other NameValue object) and add it as a property on the Visit class.

Then when you instantiate the Visit instance, you also instantiate a new Category. How you do that is up to you. You could forward it the SqlDataReader so the Category is responsible for the data access, or you could retrieve the two values from the reader in the Visit class and then pass them to the Category's constructor.

Alternatively, you could take a look at the Entity Framework, with the Code First option in particular, as EF takes care of all of this for you.

Cheers.

Imar

huambo · December 30th, 2011, 08:33 AM

Imar,

Thanks for the suggestion! This would work for lists of value pairs like categories, statuses, etc.

I wonder if, for example, you also need to get the patient's last and first names?
That is, for each visit object that you load from the database, you make another call to the patient table to get the patient info.

The real question is: is it 'cheaper' to build the result set on the server by joining the visit, patient, visit status, visit category tables and then just consume that?

My problem with this last option is that it defeats the purpose of building a layered architecture?

Thanks,
Happy Year!
Huambo

Imar · December 30th, 2011, 08:45 AM

Quote:

My problem with this last option is that it defeats the purpose of building a layered architecture?

Yes, it's cheaper as you only need to make one call.

Not sure if it breaks the design. Your Visit class can be considered in charge of its sub data.... A stored proc would be able to query all Visit related data.

Cheers,

Imar