Hi Alejandro

I remember it like this: an invoice is a real object in a business = BO. An Invoice contains at least four tables, Header, Details, Customer, Products. They are Data Objects. Business Rules would apply to each invoice. Data Rules might apply to the tables.


>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