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

This really just depends on how it will get used. My first guess would be that price is essentially a product thing. I.e. the product defines a base price that is thus modified based on the other factors, such as customer, transaction, quantity. This would mean that you would need to grab the appropriate product records from the database in order to do the calculation. If this is the case, I'd make it a method in products BO. However, it might need to be a static method, which then loads the appropriate data from products as needed.



But that is only one possibility. Another is that this would make the most sense as a separate class, that then uses the BOs needed to gather the data (or maybe the data is just passed in). This would make sense especially if you have other methods that are similar (price related logic).



You really just need to think about the data you'll be passing, the data you'll need to retrieve (if any) and how you'll use it. Ultimately, when I run across situations like this (were it is not immediately clear where to put come method), I do a bit of thinking, take my best guess and then refactor if needed later.

That gives me a bit of food for thought.... I'll chew on it

Thnaks again for your comments

Hi,

I guess you could also do the heavy lifting in the database as it sounds as though the price is going to highly data driven.

Cheers, Peter

Hi Peter.

Putting the code  in the Database  does sound like a good idea, but can I refer to SF business objects from within database stored procedures ? .

Hi Gerard,

Nope, unless you are using a CLR Stored Procedure.  Stored Procedure can really help you in many cases to handle the pressure and producing fast results.

Edhy Rijo

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.