Tony,

>From reading one of your articles at http://portal.dfpug.de/dFPUG/Dokumente/Konferenzen/VFP-Konferenz%202002/55_E-NET4.pdf, it seems to me that your architecture is contrasting that of Microsoft for example IBuySpy portal.

IBS does not have a business object layer, just a DAL. IBS is very thin in the middle tier. The ASP.NET codebehind (presentation tier) directly instantiates and calls the DAL which just delegates to stored procs. Do not take IBS as a reference architecture for creating a middle tier.


>Your BusinessObject contains a table name, a field list, GetDataSet() methods so database access mechanism is contained within the business object itself. Microsoft has two sepate objects, a business object that calls a corresponding database object that accesses database for it. I would imagine that with a true n-tier architecture, business objects should not know any thing about the database (i, e. table name and query string). What are your thoughts on this?

You are very correct to say that the business objects shouldn't know about the database and MM.NET supports a fattening of the DAL. See the docs on how to subclass the dataaccess class for each of your business objects. Still, I would like to see the mechanics of data persistence furthur abstracted away from the business objects.

ADO.NET supports a tablemapping property so that your column and table names in the DataSet do not have to match the physical data schema.