Business logic on multiple objects - where to put the loop?

Question

...and how best to handle success/failure feedback to a view layer.

Assuming that the business objects will be iterated over in the business logic method if the loop is put there (i.e. not a bulk update operation), code options in the view logic are:

doBusinessLogic( Set businessObjects )

or

for (businessObject : businessObjects) {
  doBusinessLogic( businessObject )
}

Sense would say that the former is correct, as it gives control of optimisations, etc. to the business logic method. However, this vastly complicates error handling and feedback to the view layer (assuming you are aiming for a consistent error handling/presentation model).

Assuming that we want a view layer that receives success/error feedback in a consistent way (i.e. from single or multiple business object operations), what is the best approach?

Clarification:

Handling multiple exception types thrown from a business logic call back in the view layer is code heavy and also causes maintenance problems (new exceptions are introduced which the view logic doesn't know about). The ideal is for a business logic method to handle errors in its own layer and "package" them for the view to deal with in a consistent way.

Answer 1

How about something along the lines of your latter suggestion:

for (businessObject : businessObjects) { businessObject.doBusinessLogic() }

The idea is to put the business logic in a method of the business object. Your view layer can loop over all the business objects, telling each one to do their business. How each does its business is in the logic of the business object in the business layer. You can handle errors and such by returning values from the doBusinessLogic method or by throwing exceptions for nasty occurrences.

If you are doing cross-business-object logic (i.e., logic that operates on more than one single business object), perhaps you could build a businessObjectManager class that could have methods that take in one or more business objects and operates on them. Thus, by putting the manager object in the business layer, you still keep all of your business logic in the business layer.

Answer 2

Ultimately I went for the former option and created a lightweight generic "result bundle" class that encapsulates successes and failures of an action on a collection of objects. A success or failure is keyed to the corresponding object identifier.

One if these bundles is populated inside each business logic call and then passed back across the system boundary to the view layer. Exceptions thrown in the "perform action on object" loop are caught and a corresponding failure added to the result bundle (keyed to the object ID).

The view layer has a simple helper method that presents the feedback contained in the result bundle to the user.

This works very well.

I think the approach you take with this is whatever fits best with your system.