A section in Effective Techniques mentions using Forms to construct global business object (maybe not exactly that, I left the book at work). Since the form class is the only class with a Data Environment you can ensure that the functioning of the business rules do not affect any of the active cursors that your form or procedure is looking at. I haven't seen this technique mentioned in many places so maybe people have already been down this path and found it to be a dead end? I am using it in a situation where I need a global object to assign a rate to a time/cost transaction.
Any comments about this approach? -- Michael Chean
Off hand, I can think of a reason why you wouldn't want to use a form, lots of properties and methods, so if you don't hide them all there's a lot to pass around especially if this scales to DCOM. You can use a Session Class to get a unique Data Session too, and it's very light weight, plus there are less base properties to hide form the outside world. -- Mike Helland Form Set may be a better choice if weight is an issue. - Lauren Clarke
Effective Techniques recommends a form because at the time the book was written is was the only way to get a Private Data Session. This is now changed with the Session class, introduced in SP3. It is much lighter weight than the form class. -- Craig Berntson
But the Form Set base class has always had a private data session...-- Steven Black
But the formset is difficult to create visually without a form in it. The form was used because the form is easily created both visually and in code and it has a private data session. There is no big issue here. Jim Booth
Take a look at Business Object Architectures
[2001.04.08 03:23:02 AM EST]
The way we work is so much different from what we may call the "offical way", that I hardly can contribute. However, I am sure there is another way since we use that other way, and so the contribution may be somewhere there.
What I recognize on subjects like this, is that everybody starts (thinking) with the Objects, whereas we start with the data; thinking of the logical datamodel being the first thing to design and representing the business rules, that may be right. Or ?
Now once the DataRepositary is there, the potential connection between Functions is there too; IMO a DataRepositary is old-fashioned, not because it is nowadays defined as such, but because I think this;
Already some 14 years ago, I thought DataRepositary is fine, but should be replaced by a FunctionRepositary, which nowadays is described as API, DCOM (don't know too much about that not being a real technitian (?); our main app (?ERP) this way back was developed in Fox-Dos, having Functions behaving like Objects already, though technically they weren't of course. Now since our app was converted to VFP, we maintained the Dos-programs, and called them Functional Programs. Besides that we have the "Event Model", consisting of the normal Object-stuff, and NOT containing any business-rule whatsoever.
Two (IMO) important things follow of this :
1. The Event Model can be replaced by any other;
2. The Functional Programs = business rules can be replaced by any other.
Where this all can lead to, we are not sure ourselves yet, but for sure we will be working on letting the complete app operate in the Browser, by developing another Event Model, leaving the Functional Programs untouched (again);
Where all Functional Programs are undependant of eachother, they somehow will be API's or whatever (still don't know too much about it) adapting to the Guy and Event-handling (ie Browser).
Though all of this may be nonsense (we did not "invent" it like this, but all of this should follow from logic (??)), it is -I think- a very different point of view, it might lead to the solution of this subject : having the business independent of the Guy and Event-handling, where the latter is very dependent of the Guy itself.
Please note that the way we work, is developing "old-fashioned" procedural business-code, not even seeing the Object- and Event-result while developing; it just comes all together in the runtime, which we too don't see (the user does of course). What I say is : where we develop business rules only for 100 % sure, and where all Objects follow automaticaly from these business rules (which by themselves lagely follow from the datamodel), this is one way. And no, I am surely not saying this is THE way.
Please feel free to comment on this or even better (for us) : make clear that this leads to nothing.