>Getting back to what you said about "evaluating rules", isn't it the role of DAL to come across a broken rule set in the database? For example, a UNIQUE value rule that is set in the database; how would my Business layer "know" if this rule is broken until the data is sent to DB via DAL? Or am I missing something again?

That can be handled in many ways also. In the app I used to work with, we had a Rules framework that all the controls worked with, so controls would turn themselves red if a rule was broken. For example, for a TextBox bound to a required field: if the user did not enter anything into that TextBox, as soon as they tabbed out of it, the TextBox automatically called the RuleChecking methods and the background would turn red. Likewise for controls that contained invalid data, according to the Rules.

In the case of a UNIQUE value constraint in the database, yes you could try and save your data first and if there's an error send it all back to the UI. Or, you could let your biz class query the database for you and let you know if the value already exists, rather than wait until the save. In the case of our Rules framework (which can be considered biz classes), we'd have a UniqueRule set up for that particular field. When the user tabbed out of the TextBox, the UniqueRule would send a quick query to the backend (in this case, I think it may have done it only if the value changed ... I can't remember exactly, I'm going from memory).

That help?

~~Bonnie