Hi,
I must admit to not have read the BO book, and I'm sure everything is covered in there (I'll probably get my hands on a copy within the next week though :-)
Anyway, my questionning is along the lines of "when and what". I can understand the concept of encapsulating the data into BOs, but how does one "cut to pieces" the application domain ?
Let's take the example of an order entry system. We have Customers, Orders, Order Details and so on, and these are all candidates for BO encapsulation. From the few samples I've seen, I'd have a Customer object that exposes properties and also a list of Orders. That's all fine for the "order entry" form, but I wouldn't need to expose Orders in the "Customer maintenance" form. Does that mean that one would have specialized versions of the Customer class for different uses ? Or is the general idea to design the BOs in such a way that they reflect the table relations, and only "fill" the required data for the task at hand ?
Another example is if I simply need a list of Customers to fill a ComboBox for easy lookups. It wouldn't make much sense to also fill the child Orders just for that. Would I simply re-use the Customer class and not fill the Orders, or would I create a CustomerForLookups class ?
I hope my question makes sense :-)
Regards,
Luc
The fundamental rule is that you design your objects based on what you need the object for. As Rocky has said, design your objects based on the behavior, not data.
Jav
Ok,
so according to this simple rule, I might end up with many Customer classes, one for each "use case" ?
You might do a search on the old site as this was a major discussion there. In my case I use a kind of two tier approach. I have a set of BOs that I consider to be data facing. As in your example I would have a Customer BO that reflects the database. It might have one or more child collections if the customer data also had a one to many structure. For example the customer table might have the typical data including address and so forth. But there also might be a contacts table if the Customer had more than one contact in the organization. I would also have a class for an order and a collection for order items. But the customer class would not have as it's child collection it's order history. Instead I would create a second tier class I would call OrderEntryManager. This class would be the behavior oriented class. It would be used to instantiate the Customer BOs and the Order BOs and what ever else was needed to do Order Entry. This way if you wanted to do just a simple Customer maintence funtcion you could use the Customer BO and it's child collections. To do order entry you would use the OrderEntryManager. If you had other major functions that required the use of the customer data you would create other manager classes to reflect the requirements of those functions.
Using this approach I am able to take full advantage of code generaters like CodeSmith while avoiding the problems of trying to make all my business classes look like my database. Others use other approaches as you will find in the old site.
This question seems to keep coming up. You could also do a search on this site as I know this same issue has been discussed here. If you do a search you will find that there are many ways to approach the issue you brought up.
Copyright (c) Marimer LLC