As some other type of abstraction. Basically we have some core data classes that wrap themselves around a DataSet, some DataAdapters, etc, with properties to retrieve the data from the underlying dataset (and do all of the updating/deleting/inserting automatically). Basically my own version of a strongly-typed DataSet, complete with wizards to generate all the code for you.
Then the business object simply has a reference to the data object, does any sort of business rules, etc, also has properties for all the fields, and forwards them on to the data object. Transactions are handled in the database, or in COM+ if absolutely necessary (although not usually necessary). The goal of our abstracted data classes were to give us the ability, if necessary (and I doubt it will ever be necessary), to rewrite the data layer for any data source, and have the business layer not know the difference, and to provide very simple access to get at your data. Both of which it does, and it does both incredibly fast (however I am positive it wouldn't necessary scale well to an "enterprise" system, with thousands of concurrent users, unless you had a large cluster of webservers). Adam.. -----Original Message----- From: Howard Pinsley [mailto:[EMAIL PROTECTED]] Sent: Friday, May 17, 2002 11:36 AM To: [EMAIL PROTECTED] Subject: Re: [DOTNET] OT: N-Tier Design >>None of our business objects have any notion of using SQL. Our DAL has the >>methods to do execute and return the appropriate data. And how is that data represented that is returned from the DAL to the BLL? As a dataset or some other abstraction? You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
