The problem stated in Design Challenge can be broken into three parts:
1. User Interface
2. Object Model
3. Data Model
Let us tackle each part separately and finally glue them together.
1. User Interface: User interface as depicted in IMAGE-1 requires that data to be populated in State list depend on selections in Country list. Similarly City list picks up cue from State list and finally PIN/ZIP list depends upon selection in State list. This type of pattern is also present in IMAGE-2, 3, 4 & 5. The traditional solution for this problem is to load page on each selection which affect subsequent list. But this results unnecessary heavy network traffic. To solve this problem AJAX is most efficient and contemporary answer.
Few of the AJAX frameworks which can tackle this challenge are
a. Direct Web Remoting (DWR)
b. JSON-RPC-Java
c. AJAX Tag Library
d. AjaxAnywhere
e. ZK
f. Google Web Toolkit
g. The Yahoo! User Interface Library (YUI)
h. Microsoft Ajax Library (formerly ATLAS)
i. Ajax.NET Professional
j. Dojo
k. Script.aculo.us
l. Mochikit
m. jquery
2. Object Model: Assuming one to one correspondence in data model and object model, I can assume that following object model exists.
IMAGE-7
To categorize customers, one will build population criteria. This population criterion will be composed of AgeGroup, Status, Role, Gender, Country, State, City and PIN/ZIP Code. So there must be one class corresponding to Population Criteria. To hold customers as per population criterion there should be a class.
IMAGE -8
3. Data Model: To hold data for selection criterion and population there seems to be two tables required.
IMAGE-9
Notice that TB_PopulationCriterion has only three columns ID, Name & Description. There is no provision to store selection criterion. So, how to store it? There are few ways to store it.
Option 1: Create columns pertaining to AgeGroup, Status, Gender, Role, Country, State, City and PIN. Insert multiple rows pertaining to each criterion. This will result in multiple row insertion for a single population criterion in TB_POPULATIONCRITERION. This will also results in null columns. Updation of population criterion will be difficult, so recommended way is delete and then insert new rows. This option will require change in table structure in case if any new criterion is added over time period.
Option 2: Create columns pertaining to AgeGroup, Status, Gender, Role, Country, State, City and PIN. Insert only one row pertaining to one population criterion. This approach will require comma separated string to be made while inserting and then parsing it when taking data out. This approach is again afflicted by following issues:
a. Updation of population criterion will be difficult, so delete row and insert new.
b. Need parsing code in object model.
IMAGE-10
Option 3: Store Java/C# object of Population Criterion and parse as needed. This approach has its own pitfalls:
a. Storing of Java/C# /etc. object will mandate that BI tool which will insert dynamic Population Criterion will also understand Java/C#/etc.
b. Storing binary object may pose its own problems like mismatch in object versions.
c. Stress on persistence layer.
IMAGE-11
Option 4: Store XML version of Population Criterion object. This approach seems to be very conceivable but raises following points:
a. Object Model has to support parsing logic of XML file.
b. XSD to be developed.
IMAGE-12
Option 5: This approach is most dramatic but seems to be easiest. Store SQL queries pertaining to:
a. Selections made in IMAGE-1
b. Data to be inserted in TB_POPULATION
IMAGE-13
I will appreciate your views.
Wednesday, April 15, 2009
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment