Hi Tim,

>Doesn't the chain of responsibility sort of take care of itself with regards to the Form knowing if the record is a new or an edit? The form in his case is instantiated with a -1 for the PK, then it needs to call a method on the Biz Obj that passes back data with any default values included first in the new row. Like you said, the biz obj can take care of everything, but the form is going to know because it is in the chain of responsibility.

If the Form *needs* to know, yes it would know because it *does* receive the key. However, you're most likely calling the same Biz method regardless of the value of the key and the Biz method determines whether to retrieve data from the database or send you a new dataset with defaults. So, the form really doesn't care.

Now, that said, we use Web Services, so our process *is* slightly different. As I mentioned before, if you know you're adding new data, why bother hitting the database. When I mentioned that before, it was in relation to the Form directly calling a biz method (not going through a Web Service method) and the biz method decides whether to hit the database or not. Well the same applies when using a Web Service, however in this case, you don't want to "pass the buck" on to the biz method through the Web Service if you're not even going to be hitting the database.

In this scenario, the Form *does* check to see if the key is -1 (or 0, or whatever you're using to determine this). If not, it calls the Web Service method. If so, then we call a client-side biz method. Most of our biz classes are strictly server-side, because they use DataAccess classes and methods. But we also have what we call client-side Biz classes that live in either layer (client or server), but contain no DataAccess at all.

>This is good discussion because it helps to set out how the process could/should work.

Presenting several different scenarios on how this could all work is beneficial, I agree. =0)

~~Bonnie