Re: Multilayer applications

From: Just D (no_at_spam.please)
Date: 07/24/04 

Date: Sat, 24 Jul 2004 11:57:08 -0700

Hi,

> This forces you to make sure the actual data is present in the dataset.
> Your

That's only one call to your SqlWrapper like:

public bool IsDataSetOK(DataSet ds)
{
    return ((ds!=null)&&(ds.Tables.Count>0)&&(ds.Tables[0].Rows.Count>0));
}

> business object is not constrained in needing to contain
> the actual "display" data, e.g Your Employee object has a EmployeeName and

Not exactly, it depends what data do you need at this moment, but you easily
can add a column manually and add some calculated data to this column.

> DepartmentName properties. But
> internally the Employee object only knows the Department key and is really
> calling DepartmentsCollection[key].DepartmentName to provide the
> "display" data. Getting the same behavior from a dataset is not so easy. I
> like the ability to make my business objects "self serving".

Not so easy?! Why? What about sql queries (and maybe subqueries) providing a
comprehensive information? You can join on this DepartmentKey a few tables
getting all required stuff into additional DataSet column and reflect this
column in the DataGrid automatically just from one database call, it's
easier than retrieve the whole information in two or more datasets, then
make a foreach loop every one when you need to compare two or more tables.
In a SQL solution everyting should be solved by SQL engine itself.

> But selecting an employee from a dropdown list of 1000 employees can be
> handled with some javascript and a hidden field.
Yes, but these is only one solution, You can use LIKE '%!@!#!@#%' in your
queries to get only required records by mask, you can sort them by the
alphabet and return only required group, there are many different methods.
You also can use browse feature of SQL queries, etc.

> My method does not distribute the XML file. It uses this metadata to
> generate a database class and business object abstract classes.
> I change the XSLT around to suit the methods I want for the particular
> project. Sometimes I pass the business object to the
> stored procedure method and let it get the values it needs from the object
> rather than populating a long list of parameters.

That's interesting.

Thanks,
Dmitri