::About how to organize business objects. I struggled with this a number of years ago until I ::had a BFO on the matter that was triggered by working through a design using Use Cases. I dont want to be to negative, but if you would present this in any roject of mine as an OO model, I would send you into an introductory course for OOAD, and definitly remove you from responsibility of the design until you have another BFO. Having a business object called "PrepareOrder" that only knows how to prepare an order and to talk to the DAL about preparing an order is a lot of good things, but it is NOT an object oriented system. It is the kind of twisted insane OO that MS has been pushing around for a long time. Have you ever had a look on working with business objects? The type where you have Order and OrderItem classes that you create and attach, and then just commit on the business layer which takes over all responsibility? Besides that non eof the classes should know how to talk to the DAL - it is not the business of a business object to talk to the DAL.