I have a number of Busines Objects (e.g. Customers,Products,Specialproces,TransactionHeader,Transactiondetail) and one common requirement is to return a Price, which is based on ALL these business objects. e.g. A Customer Price can be dependent on who the Customer is, what the Product is, the Transaction date and the Qty ordered.

My method would be somsthing like

Getprice(string Customer , string Product, date Trandate, double QtyOrdered, out SpecialPricce)

{  }

This price will normally end up in the Transactiondetail Business Object , but not always if for instance I am just doing an enquiry.

I am wondering where is the best place for this, In one of the Business Objects above, or a separate Class

Any comments would be welcomed

I'd consider using a sproc in the database if there was a lot of data access requirements and you really needed the speed. However, even if you do this, you likely will need to have code that calls the sproc somewhere anyway...back to the same question.  Also, if you use the FillMultipleDataTables static method of BusinessLayer you can actually get data from multiple BOs with one trip to db, so that would be fast. The other issues I've had when putting business logic in the database are:

- the business logic is now distributed between tiers, which makes it harder to maintain. There are good cases for doing this (see below), but I'm a bit more careful now about when I do this.
- Typically it can be harder to update the database than to update the application. The DDT helps a lot, but my preference is to minimize updates to the database if I can help it. Since this is business logic and could change, I'd tend to put it into the app. Also, you might find that this changes a lot and you actually need to drive the logic via something like a configuration file or meta data in the database, in which case, it is typically much easier to implement in the application.

The other side is speed. If you need speed, then the database is often the way to go. This is especially true for complicated reporting needs or algorithms that need lots of data access. E.g. if you had to get data from table 1, check if X is true for every column, grab data from Table 2, otherwise grab data table 3, then build a temp table to do an intermediary calculation, lookup data Table 4, etc... then it is way more efficient to do it at the server. With CLR sprocs, you can now handle really complicated logic and have speed too. 

Fot this routine, to get the price, i think I'll go with it in one of the business objects, as it will tend to be used to get a price at a point in time, and even though losts of tables will need to be queried, each table will normally only return one record.

Even though speed will be an issue in a very intensive heads down data entry, I am inclined to go with the proposition of putting the business rule into the business logic, rather than the database. If speed becomes an issue, I can review it and perhaps move it to a CLR in the database

That's the approach I'd use.