The Façade Pattern

18. The Façade Pattern The Façade pattern is used to wrap a set of complex classes into a simpler enclosing interface. As your programs evolve and develop, they grow in complexity. In fact, for all the excitement about using design patterns, these patterns sometimes generate so many classes that it is difficult to understand the program’s flow. Furthermore, there may be a number of complicated subsystems, each of which has its own complex interface. The Façade pattern allows you to simplify this complexity by providing a simplified interface to these subsystems. This simplification may in some cases reduce the flexibility of the underlying classes, but it usually provides all the function needed for all but the most sophisticated users. These users can still, of course, access the underlying classes and methods. Fortunately, we don’t have to write a complex system to provide an example of where a Façade can be useful. C# provides a set of classes that connect to databases, using an interface called ADO.Net. You can connect to any database for which the manufacturer has provided a ODBC connection class—almost every database on the market. Let’s take a minute and review how databases are used and a little about how they work. What Is a Database? A database is a series of tables of information in some sort of file structure that allows you to access these tables, select columns from them, sort them, and select rows based on various criteria. Databases usually have indexes associated with many of the columns in these tables, so we can access them as rapidly as possible. Databases are used more than any other kind of structure in computing. You’ll find databases as central elements of employee records and payroll systems, in travel scheduling systems, and all through product manufacturing and marketing. In the case of employee records, you could imagine a table of employee names and addresses and of salaries, tax withholding, and benefits. Let’s consider how these might be organized. You can imagine one table of employee names, addresses, and phone numbers. Other information that you might want to store would include salary, salary range, last raise, next raise, employee performance ranking, and so forth. Should this all be in one table? Almost certainly not. Salary ranges for various employee types are probably invariant between employees, and thus you would store only the employee type in the employee table and the salary ranges in another table that is pointed to by the type number. Consider the data in Table 18-1. Key Lastname SalaryType SalaryType Min Max 1 Adams 2 1 30000 45000 2 Johnson 1 2 45000 60000 3 Smyth 3 3 60000 75000 4 Tully 1 5 Wolff 2 Table 18-1 – Employee Names and Salary Type Tables The data in the SalaryType column refers to the second table. We could imagine many such tables for things like state of residence and tax values for each state, health plan withholding, and so forth. Each table will have a primary key column like the ones at the left of each table and several more columns of data. Building tables in a database has evolved to both an art and a science. The structure of these tables is referred to by their normal form. Tables are said to be in first, second, or third normal form, abbreviated as 1NF, 2NF, or 3NF. • First. Each cell in a table should have only one value (never an array of values). (1NF) • Second. 1NF and every non-key column is fully dependent on the key column. This means there is a one-to-one relationship between the primary key and the remaining cells in that row. (2NF) • Third. 2NF and all non-key columns are mutually independent. This means that there are no data columns containing values that can be calculated from other columns’ data. (3NF) Today, nearly all databases are constructed so that all tables are in third normal form (3NF). This means that there are usually a fairly large number of tables, each with relatively few columns of information. Getting Data Out of Databases Suppose we wanted to produce a table of employees and their salary ranges for some planning exercise. This table doesn’t exist directly in the database, but it can be constructed by issuing a query to the database. We’d like to have a table that looked like the data in Table 18-2. Name Adams Johnson Smyth Tully Wolff Min $45,000.00 $30,000.00 $60,000.00 $30,000.00 $45,000.00 Max $60,000.00 $45,000.00 $75,000.00 $45,000.00 $60,000.00 Table 18-2 - Employee Salaries Sorted by Name Maybe we want data sorted by increasing salary, as shown in Table 18-3. Name Tully Johnson Wolff Adams Smyth Min $30,000.00 $30,000.00 $45,000.00 $45,000.00 $60,000.00 Max $45,000.00 $45,000.00 $60,000.00 $60,000.00 $75,000.00 Table 18-3– Employee Salaries Sorted by Magnitude We find that the query we issue to obtain these tables has this form. SELECT DISTINCTROW Employees.Name, SalaryRanges.Min, SalaryRanges.Max FROM Employees INNER JOIN SalaryRanges ON Employees.SalaryKey = SalaryRanges.SalaryKey ORDER BY SalaryRanges.Min; This language is called Structured Query Language or SQL (often pronounced “sequel”), and it is the language of virtua lly all databases currently available. There have been several standards issued for SQL over the years, and most PC databases support much of these ANSI standards. The SQL-92 standard is considered the floor standard, and there have been several updates since. However, none of these databases support the later SQL versions perfectly, and most offer various kinds of SQL extensions to exploit various features unique to their database. Kinds of Databases Since the PC became a major office tool, there have been a number of popular databases developed that are intended to run by themselves on PCs. These include elementary databases like Microsoft Works and more sophisticated ones like Approach, dBase, Borland Paradox, Microsoft Access, and FoxBase. Another catego ry of PC databases includes that databases intended to be accessed from a server by a number of PC clients. These include IBM DB/2, Microsoft SQL Server, Oracle, and Sybase. All of these database products support various relatively similar dialects of SQL, and thus all of them would appear at first to be relatively interchangeable. The reason they are not interchangeable, of course, is that each was designed with different performance characteristics involved and each with a different user interface and programming interface. While you might think that since they all support SQL, programming them would be similar, quite the opposite is true. Each database has its own way of receiving the SQL queries and its own way of returning the results. This is where the next proposed level of standardization came about: ODBC. ODBC It would be nice if we could somehow write code that was independent of the particular vendor’s database that would allow us to get the same results from any of these databases without changing our calling program. If we could only write some wrappers for all of these databases so that they all appeared to have similar programming interfaces, this would be quite easy to accomplish. Microsoft first attempted this feat in 1992 when they released a specification called Object Database Connectivity. It was supposed to be the answer for connection to all databases under Windows. Like all first software versions, this suffered some growing pains, and another version was released in 1994 that was somewhat faster as well as more stable. It also was the first 32-bit version. In addition, ODBC began to move to platforms other than Windows and has by now become quite pervasive in the PC and Workstation world. Nearly every major database vendor provides ODBC drivers. Database Structure At the lowest level, then, a database consists of a series of tables, each having several named columns, and some relationships between these tables. This can get pretty complicated to keep track of, and we would like to see some simplification of this in the code we use to manipulate databases. C# and all of VisualStudio.Net use a new database access model, called ADO.NET, for ActiveX Data Objects. The design philosophy of ADO.NET is one in which you define a connection between your program and a database and use that connection sporadically, with much of the computation actually taking place in disconnected objects on your local machine. Further, ADO.NET uses XML for definition of the objects that are transmitted between the database and the program, primarily under the covers, although it is possible to access this data description using some of the built- in ADO.NET classes. Using ADO.NET ADO.NET as implemented in C# consists of a fairly large variety of interrelated objects. Since the operations we want to perform are still the same relatively simple ones, the Façade pattern will be an ideal way to manage them. • OleDbConnection—This object represents the actual connection to the database. You can keep an instance of this class available but open and close the connection as needed. You must specifically close it when you are done, before it is garbage collected. • OleDbCommand—This class represents a SQL command you send to the database, which may or may not return results. • OleDbDataAdapter—Provides a bridge for moving data between a database and a local DataSet. You can specify an OleDbCommand, a Dataset, and a connection. • DataSet—A representation of one or more database tables or results from a query on your local machine. • DataTable—A single data table from a database or query • DataRow—A single row in a DataTable. Connecting to a Database To connect to a database, you specify a connection string in the constructor for the database you want to use. For example, for an Access database, your connection string would be the following. string connectionString = "Provider=Microsoft.Jet.OLEDB.4.0;" + "Data Source=" + dbName; and the following makes the actual connection. OleDbConnection conn = new OleDbConnection(connectionString); You actually open that connection by calling the open method. To make sure that you don’t re-open an already open connection, you can check its state first. private void openConnection() { if (conn.State == ConnectionState.Closed){ conn.Open (); } } Reading Data from a Database Table To read data in from a database table, you create an ADOCommand with the appropriate Select statement and connection. public DataTable openTable (string tableName) { OleDbDataAdapter adapter = new OleDbDataAdapter (); DataTable dtable = null; string query = "Select * from " + tableName; adapter.SelectCommand = new OleDbCommand (query, conn); Then, you create a dataset object into which to put the results. DataSet dset = new DataSet ("mydata"); Then, you simply tell the command object to use the connection to fill the dataset. You must specify the name of the table to fill in the FillDataSet method, as we show here. try { openConnection(); adapter.Fill (dset); } catch(Exception e) { Console.WriteLine (e.Message ); } The dataset then contains at least one table, and you can obtain it by index or by name and examine its contents. //get the table from the dataset dtable = dset.Tables [0]; Executing a Query Executing a Select query is exactly identical to the preceding code, except the query can be an SQL Select statement of any complexity. Here we show the steps wrapped in a Try block in case there are SQL or other database errors. public DataTable openQuery(string query) { OleDbDataAdapter dsCmd = new OleDbDataAdapter (); DataSet dset = new DataSet (); //create a dataset DataTable dtable = null; //declare a data table try { //create the command dsCmd.SelectCommand = new OleDbCommand(query, conn); //open the connection openConnection(); //fill the dataset dsCmd.Fill(dset, "mine"); //get the table dtable = dset.Tables[0]; //always close it closeConnection(); //and return it return dtable; } catch (Exception e) { Console.WriteLine (e.Message); return null; } } Deleting the Contents of a Table You can delete the contents of a table using the “Delete * from Table” SQL statement. However, since this is not a Select command, and there is no local table to bridge to, you can simply use the ExecuteNonQuery method of the OleDbCommand object. public void delete() { //deletes entire table conn = db.getConnection(); openConn(); if (conn.State == ConnectionState.Open ) { OleDbCommand adcmd = new OleDbCommand("Delete * from " + tableName, conn); try{ adcmd.ExecuteNonQuery(); closeConn(); } catch (Exception e) { Console.WriteLine (e.Message); } } Adding Rows to Database Tables Using ADO.NET The process of adding data to a table is closely related. You generally start by getting the current version of the table from the database. If it is very large, you can get only the empty table by getting just its schema. We follow these steps. 1. Create a DataTable with the name of the table in the database. 2. Add it to a dataset. 3. Fill the dataset from the database. 4. Get a new row object from the DataTable. 5. Fill in its columns. 6. Add the row to the table. 7. When you have added all the rows, update the database from the modified DataTable object. The process looks like this. DataSet dset = new DataSet(tableName); //create the data set dtable = new DataTable(tableName); //and a datatable dset.Tables.Add(dtable); //add to collection conn = db.getConnection(); openConn(); //open the connection OleDbDataAdapter adcmd = new OleDbDataAdapter(); //open the table adcmd.SelectCommand = new OleDbCommand("Select * from " + tableName, conn); OleDbCommandBuilder olecb = new OleDbCommandBuilder(adcmd); adcmd.TableMappings.Add("Table", tableName); //load current data into the local table copy adcmd.Fill(dset, tableName); //get the Enumerator from the Hashtable IEnumerator ienum = names.Keys.GetEnumerator(); //move through the table, adding the names to new rows while (ienum.MoveNext()) { string name = (string)ienum.Current; row = dtable.NewRow(); //get new rows row[columnName] = name; dtable.Rows.Add(row); //add into table } //Now update the database with this table try { adcmd.Update(dset); closeConn(); filled = true; } catch (Exception e) { Console.WriteLine (e.Message); } It is this table editing and update process that is central to the ADO style of programming. You get the table, modify the table, and update the changes back to the database. You use this same process to edit or delete rows, and updating the database makes these changes as well. Building the Façade Classes This description is the beginning of the new Façade we are developing to handle creating, connecting to, and using databases. In order to carry out the rest, let’s consider Table 18-4, grocery prices at three local stores. Stop and Shop, Stop and Shop, Stop and Shop, Stop and Shop, Stop and Shop, Stop and Shop, Stop and Shop, Village Market, Village Market, Village Market, Village Market, Village Market, Village Market, Village Market, Waldbaum's, Waldbaum's, Waldbaum's, Waldbaum's, Waldbaum's, Waldbaum's, Waldbaum's, Apples, Oranges, Hamburger, Butter, Milk, Cola, Green beans, Apples, Oranges, Hamburger, Butter, Milk, Cola, Green beans, Apples, Oranges, Hamburger, Butter, Milk, Cola, Green beans, 0.27 0.36 1.98 2.39 1.98 2.65 2.29 0.29 0.29 2.45 2.99 1.79 3.79 2.19 0.33 0.47 2.29 3.29 1.89 2.99 1.99 Table 18-4- Grocery Pricing Data It would be nice if we had this information in a database so we could easily answer the question “Which store has the lowest prices for oranges?” Such a database should contain three tables: the supermarkets, the foods, and the prices. We also need to keep the relations among the three tables. One simple way to handle this is to create a Stores table with StoreName and StoreKey, a Foods table with a FoodName and a FoodKey, and a Price table with a PriceKey, a Price, and references to the StoreKey and Foodkey. In our Façade, we will make each of these three tables its own class and have it take care of creating the actual tables. Since these three tables are so similar, we’ll derive them all from the basic DBTable class. Building the Price Query For every food name, we’d like to get a report of which stores have the cheapest prices. This means writing a simple SQL query against the database. We can do this within the Price class and have it return a Dataset with the store names and prices. The final application simply fills one list box with the food names and files the other list box with prices when you click on a food name, as shown in Figure 18-1. Figure 18-1 – The grocery program using a Façade pattern Making the ADO.NET Façade In the Façade we will make for our grocery database, we start with an abstract DBase class that represents a connection to a database. This encapsulates making the connection and opening a table and an SQL query. public abstract class DBase { protected OleDbConnection conn; private void openConnection() { if (conn.State == ConnectionState.Closed){ conn.Open (); } } //-----private void closeConnection() { if (conn.State == ConnectionState.Open ){ conn.Close (); } } //-----public DataTable openTable (string tableName) { OleDbDataAdapter adapter = new OleDbDataAdapter (); DataTable dtable = null; string query = "Select * from " + tableName; adapter.SelectCommand = new OleDbCommand (query, conn); DataSet dset = new DataSet ("mydata"); try { openConnection(); adapter.Fill (dset); dtable = dset.Tables [0]; } catch(Exception e) { Console.WriteLine (e.Message ); } return dtable; } //-----public DataTable openQuery(string query) { OleDbDataAdapter dsCmd = new OleDbDataAdapter (); DataSet dset = new DataSet (); //create a dataset DataTable dtable = null; //declare a data table try { //create the command dsCmd.SelectCommand = new OleDbCommand(query, conn); openConnection(); //open the connection //fill the dataset dsCmd.Fill(dset, "mine"); //get the table dtable = dset.Tables[0]; closeConnection(); //always close it return dtable; //and return it } catch (Exception e) { Console.WriteLine (e.Message); return null; } } //-----public void openConnection(string connectionString) { conn = new OleDbConnection(connectionString); } //-----public OleDbConnection getConnection() { return conn; } } Note that this class is complete except for constructors. We’ll make derived classes that create the connection strings for various databases. We’ll make a version for Access: public class AxsDatabase :Dbase { public AxsDatabase(string dbName) { string connectionString = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" + dbName; openConnection(connectionString); } } and another for SQL Server. public class SQLServerDatabase:DBase { string connectionString; //----public SQLServerDatabase(String dbName) { connectionString = "Persist Security Info = False;" + "Initial Catalog =" + dbName + ";" + "Data Source = myDataServer;User ID = myName;" + "password="; openConnection(connectionString); } //----public SQLServerDatabase(string dbName, string serverName, string userid, string pwd) { connectionString = "Persist Security Info = False;" + "Initial Catalog =" + dbName + ";" + "Data Source =" + serverName + ";" + "User ID =" + userid + ";" + "password=" + pwd; openConnection(connectionString); } } The DBTable class The other major class we will need is the DBTable class. It encapsulates opening, loading, and updating a single database table. We will also use this class in this example to add the single values. Then we can derive food and store classes that do this addition for each class. public class DBTable { protected DBase db; protected string tableName; private bool filled, opened; private DataTable dtable; private int rowIndex; private Hashtable names; private string columnName; private DataRow row; private OleDbConnection conn; private int index; //----public DBTable(DBase datab, string tb_Name) { db = datab; tableName = tb_Name; filled =false; opened = false; names = new Hashtable(); } //----public void createTable() { try { dtable = new DataTable(tableName); dtable.Clear(); } catch (Exception e) { Console.WriteLine (e.Message ); } } //----public bool hasMoreElements() { if(opened) return (rowIndex < dtable.Rows.Count) ; else return false; } //----public int getKey(string nm, string keyname){ DataRow row; int key; if(! filled) return (int)names[ nm]; else { string query = "select * from " + tableName + " where " + columnName + "=\'" + nm + "\'"; dtable = db.openQuery(query); row = dtable.Rows[0]; key = Convert.ToInt32 (row[keyname].ToString()); return key; } } //----public virtual void makeTable(string cName) { //shown below //----private void closeConn() { if( conn.State == ConnectionState.Open) { conn.Close(); } } //----private void openConn() { if(conn.State == ConnectionState.Closed ) { conn.Open(); } } //----public void openTable() { dtable = db.openTable(tableName); rowIndex = 0; if(dtable != null) opened = true; } //----public void delete() { //shown above } } Creating Classes for Each Table We can derive the Store, Food, and Prices classes from DBTable and reuse much of the code. When we parse the input file, both the Store and Food classes will require that we create a table of unique names: store names in one class and food names in the other. C# provides a very convenient way to create these classes using the Hashtable. A Hashtable is an unbounded array where each element is identified with a unique key. One way people use Hashtables is to add objects to the table with a short nickname as the key. Then you can fetch the object from the table by using its nickname. The objects need not be unique, but, of course, the keys must be unique. The other place Hashtables are convenient is in making a list of unique names. If we make the names the keys and some other number the contents, then we can add names to the Hashtable and assure ourselves that each will be unique. For them to be unique, the Hashtable must treat attempts to add a duplicate key in a predictable way. For example, the Java Hashtable simply replaces a previous entry having that key with the new one. The C# implementation of the Hashtable, on the other hand, throws an exception when we try to add a nonunique key value. Now bearing in mind that we want to accumulate the entire list of names before adding them into the database, we can use the following method to add names to a Hashtable and make sure they are unique. public void addTableValue(string nm) { //accumulates names in hash table try { names.Add(nm, index++); } catch (ArgumentException) {} //do not allow duplicate names to be added } Then, once we have added all the names, we can add each of them to the database table. Here we use the Enumerator property of the Hashtable to iterate though all the names we have entered in the list. public virtual void makeTable(string cName) { columnName = cName; //stores current hash table values in data table DataSet dset = new DataSet(tableName); //create dataset dtable = new DataTable(tableName); //and a datatable dset.Tables.Add(dtable); //add to collection conn = db.getConnection(); openConn(); //open the connection OleDbDataAdapter adcmd = new OleDbDataAdapter(); //open the table adcmd.SelectCommand = new OleDbCommand("Select * from " + tableName, conn); OleDbCommandBuilder olecb = new OleDbCommandBuilder(adcmd); adcmd.TableMappings.Add("Table", tableName); //load current data into the local table copy adcmd.Fill(dset, tableName); //get the Enumerator from the Hashtable IEnumerator ienum = names.Keys.GetEnumerator(); //move through the table, adding the names to new rows while (ienum.MoveNext()) { string name = (string)ienum.Current; row = dtable.NewRow(); //get new rows row[columnName] = name; dtable.Rows.Add(row); //add into table } //Now update the database with this table try { adcmd.Update(dset); closeConn(); filled = true; } catch (Exception e) { Console.WriteLine (e.Message); } } This simplifies our derived Stores table to just the following. public class Stores :DBTable { public Stores(DBase db):base(db, "Stores"){ } //----public void makeTable() { base.makeTable ("Storename"); } } And it simplifies the Foods table to much the same thing. public class Foods: DBTable { public Foods(DBase db):base(db, "Foods"){ } //----public void makeTable() { base.makeTable ("Foodname"); } //----public string getValue() { return base.getValue ("FoodName"); } } The getValue method allows us to enumerate the list of names of Stores or Foods, and we can put it in the base DBTable class. public virtual string getValue(string cname) { //returns the next name in the table //assumes that openTable has already been called if (opened) { DataRow row = dtable.Rows[rowIndex++]; return row[cname].ToString().Trim (); } else return ""; } Note that we make this method virtual so we can override it where needed. Building the Price Table The Price table is a little more complicated because it contains keys from the other two tables. When it is completed, it will look like Table 18-5. Pricekey Foodkey 1 StoreKey 1 Price 1 0.27 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 2 3 4 5 6 7 1 2 3 4 5 6 7 1 2 3 4 5 6 7 1 1 1 1 1 1 2 2 2 2 2 2 2 3 3 3 3 3 3 3 0.36 1.98 2.39 1.98 2.65 2.29 0.29 0.29 2.45 2.99 1.79 3.79 2.19 0.33 0.47 2.29 3.29 1.89 2.99 1.99 Table 18-5 – The Price Table in the Grocery Database To create it, we have to reread the file, finding the store and food names, looking up their keys, and adding them to the Price table. The DBTable interface doesn’t include this final method, but we can add additional specific methods to the Price class that are not part of that interface. The Prices class stores a series of StoreFoodPrice objects in an ArrayList and then loads them all into the database at once. Note that we have overloaded the classes of DBTable to take arguments for the store and food key values as well as the price. Each time we add a storekey, foodkey and price to the internal ArrayList table, we create an instance of the StoreFoodPrice object and store it. public class StoreFoodPrice { private int storeKey, foodKey; private float foodPrice; //----public StoreFoodPrice(int sKey, int fKey, float fPrice) { storeKey = sKey; foodKey = fKey; foodPrice = fPrice; } //----public int getStore() { return storeKey; } //----public int getFood() { return foodKey; } //----public float getPrice() { return foodPrice; } } Then, when we have them all, we create the actual database table: public class Prices : DBTable { private ArrayList priceList; public Prices(DBase db) : base(db, "Prices") { priceList = new ArrayList (); } //----public void makeTable() { //stores current array list values in data table OleDbConnection adc = new OleDbConnection(); DataSet dset = new DataSet(tableName); DataTable dtable = new DataTable(tableName); dset.Tables.Add(dtable); adc = db.getConnection(); if (adc.State == ConnectionState.Closed) adc.Open(); OleDbDataAdapter adcmd = new OleDbDataAdapter(); //fill in price table adcmd.SelectCommand = new OleDbCommand("Select * from " + tableName, adc); OleDbCommandBuilder custCB = new OleDbCommandBuilder(adcmd); adcmd.TableMappings.Add("Table", tableName); adcmd.Fill(dset, tableName); IEnumerator ienum = priceList.GetEnumerator(); //add new price entries while (ienum.MoveNext() ) { StoreFoodPrice fprice = (StoreFoodPrice)ienum.Current; DataRow row = dtable.NewRow(); row["foodkey"] = fprice.getFood(); row["storekey"] = fprice.getStore(); row["price"] = fprice.getPrice(); dtable.Rows.Add(row); //add to table } adcmd.Update(dset); //send back to database adc.Close(); } //----public DataTable getPrices(string food) { string query= "SELECT Stores.StoreName, " + "Foods.Foodname, Prices.Price " + "FROM (Prices INNER JOIN Foods ON " + "Prices.Foodkey = Foods.Foodkey) " + "INNER JOIN Stores ON " + "Prices.StoreKey = Stores.StoreKey " + "WHERE(((Foods.Foodname) = \'" + food + "\')) " + "ORDER BY Prices.Price"; return db.openQuery(query); } //----public void addRow(int storeKey, int foodKey, float price) priceList.Add ( new StoreFoodPrice (storeKey, foodKey, price)); } } Loading the Database Tables With all these classes derived, we can write a class to load the table from the data file. It reads the file once and builds the Store and Food database tables. Then it reads the file again and looks up the store and food keys and adds them to the array list in the Price class. Finally, it creates the Price table. public class DataLoader { private csFile vfile; private Stores store; private Foods fods; private Prices price; private DBase db; //----public DataLoader(DBase datab) { db = datab; store = new Stores(db); fods = new Foods (db); price = new Prices(db); } //----public void load(string dataFile) { string sline; int storekey, foodkey; StringTokenizer tok; //delete current table contents store.delete(); fods.delete(); price.delete(); //now read in new ones vfile = new csFile(dataFile); vfile.OpenForRead(); sline = vfile.readLine(); while (sline != null){ tok = new StringTokenizer(sline, ","); store.addTableValue(tok.nextToken()); //store fods.addTableValue(tok.nextToken()); //food sline = vfile.readLine(); } vfile.close(); //construct store and food tables store.makeTable(); fods.makeTable(); vfile.OpenForRead(); sline = vfile.readLine(); while (sline != null) { //get the gets and add to storefoodprice objects tok = new StringTokenizer(sline, ","); storekey = store.getKey(tok.nextToken(), "Storekey"); foodkey = fods.getKey(tok.nextToken(), "Foodkey"); price.addRow(storekey, foodkey, Convert.ToSingle (tok.neXtToken())); sline = vfile.readLine(); } //add all to price table price.makeTable(); vfile.close(); } } The Final Application The program loads a list of food prices into a list box on startup. private void loadFoodTable() { Foods fods =new Foods(db); fods.openTable(); while (fods.hasMoreElements()){ lsFoods.Items.Add(fods.getValue()); } } And it displays the prices of the selected food when you click on it. private void lsFoods_SelectedIndexChanged(object sender, System.EventArgs e) { string food = lsFoods.Text; DataTable dtable = prc.getPrices(food); lsPrices.Items.Clear(); foreach (DataRow rw in dtable.Rows) { lsPrices.Items.Add(rw["StoreName"].ToString().Trim() + "\t" + rw["Price"].ToString()); } } The final program is shown in Figure 18-2. Figure 18-2– The C# grocery database program If you click on the “load data” button, it clears the database and reloads it from the text file. What Constitutes the Façade? The Facade in this case wraps the classes as follows. • Dbase —Contains ADOConnection, Database, DataTable, ADOCommand, ADODatasetCommand • DBTable —Contains ADOCommand, Dataset, Datarow, Datatable, ADODatasetCommand You can quickly see the advantage of the Façade approach when dealing with such complicated data objects. Consequences of the Façade The Façade pattern shields clients from complex subsystem components and provides a simpler programming interface for the general user. However, it does not prevent the advanced user from going to the deeper, more complex classes when necessary. In addition, the Façade allows you to make changes in the underlying subsystems without requiring changes in the client code and reduces compilation dependencies. Thought Question Suppose you had written a program with a File|Open menu, a text field, and some buttons controlling font (bold and italic). Now suppose that you need to have this program run from a line command with arguments. Suggest how to use a Façade pattern. Programs on the CD-ROM \Façade\ C# database Façade classes