This is my first middle-tier project, so I can't say that what I am doing is a best practice. What I do is have a 1-1 correlation between my SQL Server tables and my business objects. Each business object, ex. Customer, focuses only on dealing with its corresponding table.

Sa far, these are pretty light-weight: I insert a new record, update an existing, load a record, etc. Also, I may retrieve the customer's credit limit within the object, return their most recent Order #, etc.

When objects need to interact with each other, as when a customer places an order, I use an event object. The event object handles the interaction between the various business objects. So far, this is where the complex business logic is going, in my event objects. Each object itself does not do very much, but when theyu interact, as when a customer places an order, things get more complex.

>I'm starting a new project and I'm trying to decide where to put complex method code (business rules?) as a standard for myself.
>
>Can somebody help me with some best practices - pro's and con's of what I should do, and the problems I will run into down the line if I do it any particular way?
>
>My concerns include embedded methods or external prg's, pathing of project components ( common (big )libraries or small local copies ) and benefits of loading a COM server once versus loading ( opening files ? ) once per transaction ( not for performance, but from a design point of view )
>
>thanks
>
>mike