>>>Hi,
>>>
>>>I kind of sort of understand the purpose and use of BIZ object. But I am a little confused on what is the better practice for BIZ object in the following case (simplified).
>>>
>>>Say you have a parts stock room system. I have a class that is used as BIZ object for validating entries in the parts stock room table. Another typical thing that has to be done in this system is posting receipt of some quantities for the parts. In the UI tier this is done in a batch mode: User has a grid-like form where he/she enters a bunch of parts and the QTY received for each part. This UI tier will then pass the information to the BIZ object that will update (via DA tier) the in-stock quantities. My question is, do I simply add a method of batch posting of receipt items to the Stock Room Parts BIZ class or is it better to have a separate class for using with batch processing?
>>>
>>
>>Seems to me you're thinking about this backwards. A set of business objects should be the "engine" for your application, handling all the operations that need to be done. The UI then simply calls on those objects to do what it needs. That is, the UI design should not drive the design of business objects.
>>
>
>I thought about this for a while and I respectfully disagree. UI would and should influence design of business objects. Business objects do not exist in a vacuum; they have to receive data from UI and the format of the data will play role in business object design.

Yes and no. There's at least one school of software design which starts from entities, which are logical groupings of data into storages (but still not necessarily one table each), which then designs the forms by following possible transactions between these groups (usually one form per transaction type), and then it's up to the designer to split the work between the presentation layer (i.e. the visible part of the app), the business layer (various validations, calculations, domain restrictions) and the data layer (i.e. physically passing the data between the business layer and the physical storage).

If you want to do this clean, your form may be your means of determining which fields you may need and where, if that's your way of thinking and app design - in that sense, it's a YES, to a point. It may influence the design if you think in forms and if they are the tool that helps you visualize what you're building. These don't even have to be forms per se, but just use cases with descriptions of what data need to be entered.

This is also a NO: GUI doesn't need to know what's in which table, exact field names, and whether the tables are dbfs, SQL, DB2, Oracle or knots on shoestrings, it only needs to know how to instantiate its bizobject(s) and tell it what to do. Also, the bizobject should not be concerned with any controls. "Textbox" is a bad word in a bizobject - it shouldn't have to know anything about the controls.