[AccessD] A question of design philosophy... n-tier

Hi Bruce:

Traditionally, in large DBs like MS SQL or Oracle these fields are populated
by triggers. Any record processing should be spawned at the DAL and with
standard design that what should happen. It takes a Save/Submit event to
start the processing.

I always add a number of fields to all tables before the rest of the design.
These are the Timestamp, Created, LastUpdated and Active. The timestamp
notes when the last lock/access was placed on the record, Created gives the
user code of the creator, the LastUpdated gives the code of the last user
editing the record and the Active field/byte indicated whether the record is
active or not and that is used to allow/disallow display of the record. (In
many accounting/transaction DBs records can never be deleted.)

I could prattle on for sometime but this covers the high points... Oh yes
never go beyond the third level of normalization unless you really can
justify it as at the juncture the performance starts to depreciate.

And always design code with the understanding that you may be required to
fix it in a couple of years.... 

Comments by
Jim       

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Bruce Bruen
Sent: Sunday, March 18, 2007 11:42 PM
To: Access Developers discussion and problem solving
Subject: [AccessD] A question of design philosophy... n-tier

Dear friends,

I just can't seem to get my head around this today, so I'm throwing it open 
for ideas.

I have "inherited" a rather nicely designed 3-tier VB application to do a 
design review on.  The UI is separate from the business object layer as is 
the data access layer, which includes an MS-Access (XP) option.  Putting
that 
another way, there is a (set of) VB apps that use logical business objects 
that depending on the selected/implemented DAL could be an MS-Access db.
The 
Access db interface is actually implemented as an mdb (mde) which executes 
stored queries in the real backend.

Now, to get down to the dirt....

There are a significant number of tables in the design that have audit 
attributes, "createdOn", "lastChangedBy", etc.

Here's the question!  Should the audit fields be set by the business logic 
layer or by the DAL?  (At the moment its a mixed bag, some are set at the
BLL 
and some at the DAL.)

By way of example,  lets say we have a business object "project" with said 
audit attibutes.  When an update is made to the object, i.e. the current 
instance of project, say MyProject, the user can at some time update those 
changes to the database.  When s/he does so, the "lastChangedBy" 
and "lastChangeDate" of the project needs to be updated by the system 
(to "currentUser" and "now() respectively).  

So what layer should ("logically", or "architecturally" or "industry
standard" 
or "best practice" or....)  be responsible?  The BLL or the DAL? 

Your input would be appreciated - either by considered answer or by survey:
[Survey]
	a) Uh????  (This is the top answer from the VB forums I use)
	b) The DAL
	c) The BLL
	d) What does it matter,  the real question is "Does it work?"
[/Survey}

-- 
regards

Bruce
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com