| | | StrataFrame User
       
Group: StrataFrame Users Last Login: Yesterday @ 12:50:49 AM Posts: 217, Visits: 1,057 |
| | Hi, A bit of general input please. I’m currently investigating how we will implement reporting using DevExpress XtraReports. We are going down the XtraReports path because we use DevExpress controls and, hoperfully, just keeping our development toolset to StrataFrame and DevExpress will make life easier and XtraReports looks like giving us all we want in a report writer. I’ve been back through the forum looking at all the ‘reporting’ posts and it seems as though using SF BO’s for reporting has been successfully implemented around the place although, I must admit, I haven’t been able to manage that trick yet. However, what I have seen so far concerns me in that getting data into a report appears to involve first getting a report’s data into the BO’s used in a report then doing a table copy to get the data from the BO’s into the report itself. I see this as being somewhat inefficient and, as our system it used by quite a few reporting users during production (average inserts of 40 or so new transactions every minute into an 11 million row transaction file) then efficiency is always front of mind. The application uses thin clients under terminal services so, in our case, there’s no advantage in storing copies of data in BO’s that are local to the user’s PC. It seems to me that using Table Adaptors to execute stored procedures to get the data into our reports is the best way to go but I wonder if anyone would care to comment on the benefits of using SF BO’s over Table Adaptors and/or the disadvantages of Table Adaptors. Indeed, maybe my understading that report data must first populate BO's then be copied as a table into the report is off target. Cheers, Peter
|
| | | | 
StrataFrame Developer

Group: StrataFrame Developers Last Login: Today @ 11:54:01 AM Posts: 4,104, Visits: 4,177 |
| | OK...this was an entire topic that I have been planning on posting on the upcoming knowledge base, but I will give you a preview here before you get too deep. We have already gone through all of this with our medical software and there is really only one really good way to go about this, and I also know for a fact that we have other developers using XtraReports with this logic. You will want to create a BBS that wraps your BO and then attach that BBS as your datasource on your report. What we generally do is create a unique BO that inherits the parent BO for each report so that we can add custom properties, etc that are specific to that report. It is MUCH cleaner (and safer) than adding those properties on the base BO. Step 1 - Create the Inherited Report BO Namespace MyReportName Public Class CustomersBO Inherits MyApp.Business.CustomersBO End Class End Namespace Step 2 - Create a BBS for the report that wraps the new BO
Here is a forum post that shows how to do this: http://forum.strataframe.net/FindPost12959.aspx At this point, you are ready to map that BBS class as your datasource for your report. This is the ONLY way that I would recommend doing reports. If you go down the table adapter approach then you are starting to work outside of the framework as it relates to managing and gathering data and you lose strong-typing and the strength of using a BO. I will be posting reporting samples when the KB is released and have a replete article on this very topic. |
| | | | StrataFrame User
       
Group: StrataFrame Users Last Login: Yesterday @ 12:50:49 AM Posts: 217, Visits: 1,057 |
| | Hi Trent, Thanks for that. I don't know what your plans are for the KB but I would urge SF to publish sections as they are completed rather than waiting until the entire KB is 'finished'. The piece on reporting can come asap for my money. Cheers, Peter |
| | | | 
StrataFrame Developer

Group: StrataFrame Developers Last Login: Today @ 11:54:01 AM Posts: 4,104, Visits: 4,177 |
| | Hey Peter, yeah this is good advice and is pretty much where we have landed. We still have some logistics to get worked out whcih will be the primary thing. Then we will start posting topics. But I think that you are right on this! |
| |
|
|