You definately don't want one BO per table. That's the purpose of the data objects (DO). The UI calls the BO which calls the appropriate DOs. For example, you'll have a class schedule for each student. You should have a class schedule BO. It will then call multiple DOs to save, update, retrieve data.


>Hi,
>
>I am designing a school administration app with data in SQLServer and would like to understand what are the related best practices. BTW, I won't be using a commercial framework since I would like to do it as open source, so this is a newbie question for both BOs and SQL Server.
>
>To be in fashion :) the first thought is to create a BO class for each table.
>
>1) I have read that each BO should contain an instance of a data access class to make it independent of the storage mediun (A cursor adapter seems ideal for this. Is it?).
>2) In other cases SQLPT seems more natural. For example, if GetClassesOfOneStudent() was a method of the StudentBO, SQLPT seems the most direct way to get the data. It may call a stored procedure, but not for the moment.
>3) While it seems that there should basically be one BO per table, what do you do when a method involves data from more than one table, as in the above example? Do you have to go to a compound BO?
>4) I am considering grouping many business rules in a global business object. Does that make sense to you?
>
>Thanks for the help.
>
>Alex