Hi,
We are currently designing a new architecture for our software. We are two architects on this project, and we are currently having a big discussion on the use of ProDataSets.
Here is the point : We have settled a 3-Layer architecture : UI - business - data, using ProDataSets as the "data vehicle" between layers. But PDS have a powerfull set of features that we could use ; the callbacks (example : AfterRowFill). Is there anyway to use it without breaking the layered arch ?
Here is an example : We need to display prices of an article for a list of clients. It implies that we use a rule to calculate the price depending on the client. This rule is a "business rule", right ?
So, the first idea is :
1 - I load the data I need from the data layer into the business layer
2 - In the business layer, I use my rule, my raw data and I calculate my price to complete my PDS
But I have two loops ! One to load the data for each client in the data layer and another one to calculate the price !
And I have this cool feature, AfterRowFill, on my PDS that allows me to do this in only one loop, at the price of breaking my layers...
Should I bother to have only one loop ?
Should I be strict on my layer model ?
Could I have your thoughs about that ?
Is there a way to combine both strenghts ?
Thanks a lot !
When the data is loaded into the BL, does the method CalculatePrice need to query more data in the database, or it has all it needs in the dataset ?
And we're talking about how much records ?
At first, I was thinking that the DL collected all data needed then passed it to BL.
Then BL use his CalculatePrice method on this data.
For the number of record... I don't know, it's kind of a general architecture question about data loading, from 1 row to 100.000.
I know that it depends a bit on that, but I'd llike to find a general way of conceiving the architecture of my app...
Thanks
I think it's hard to find a one fit all solution. We always try the pure and strict approach first, but we have found that with current ABL, all this layers separation and isolation of reponsabilities, we quickly hit performance problem and need to do compromise. Maybe we're doing it wrong, there is not a lot of real world examples out there.
In your case, all the required data is in memory, I don't think you'll have performance problem iterating over your temp-tables.
But if you do, I would make the AfterRowFill in the data layer call a business class to calculate and return the price.
If you really want to make your DL unaware of the BL, then you could define an interface in the DL (ex: IPriceCalculator), that contains a CalculatePrice() method, then in the BL make a class that implements this interface, and send this business class instance , as a IPriceCalculator, to your fetch method in the DL, which can use IPriceCalculator to fill the dataset.
I think we could use a little more information.
Is the price for a customer something static or is it dynamic. E.g., would it make sense to ask the Data Layer to fetch the prices for a customer and hand over data which already includes the customer adjustment? Or, is this something that is going to change during a session?
Also, I question the need to actually compute the price as a separate operation. I'm going to speak here in terms of objects, since this post is on the OO forum. Suppose you have an item object, which has a list price property, and a pricing object which knows about the list price from the item object and the customer discount from the customer object and whatever else might go into the pricing algorithm. Then, you just ask the pricing object for the customer/item price and the pricing object returns the appropriate number.
While this isn't the primary focus of your question, I'd also like to ask you what relationship you are thinking of between the PDS and the objects? You mention using the PDS like a message between the DL and BL. That sounds unfortunately reminiscent of the PDS-model proposed by John Sadd in some whitepapers from a couple of years ago. At this point, I regard it as the least desireable of four different patterns which use PDS in the BL. This is where the PDS is assembled in the DL and then sent to the BL where there is a business entity object which is basically a shell of logic which is then wrapped around the PDS. The PDS can contain either one or many instances where one of the instances is the "current" one to which operations apply. If you were dead set on using PDS in the BL, I would take a good look at the NSRA, iMo, and especially the Model-Set-Entity patterns as a better reference base. And, of course, there are some inherent issues with using a PDS in the BL. See http://www.cintegrity.com/content/Patterns-Managing-Relational-Data-OOABL for a preliminary discussion.