I'm in the process of completely redoing an app based on csla 1.x to 4.x and I have a clean slate.
When I designed the original app I decided to combine grid views and reporting. The user can filter and sort the grid data displayed in pretty complex ways and then send that to a report.
I did this with read only collection objects that take criteria from the users filter and sort choices in the UI in a special format and convert it to sql criteria.
Problem is that over the years people were not satisfied with the default fields I coded and requested more and more fields be included for reporting. It's gotten ugly and out of hand and I want to do better.
About a year ago I added a feature to be able to access my business object library from c# code behind the report. Possible because DevExpress Xtrareports supports this. This helped alleviate the field creep since people could get any data from any part of the app via the business objects.
However it sets the bar pretty high for the average end user to customize the reports. We provide a service to do it for a fee but I'd rather just make it easy for the end user to do it themselves.
Now that I have a clean slate I'm wondering how people normally handle this scenario. Our app is a business app with fairly complex hierarchy being reported on in some cases (like grandchild deep collections in some cases).
Reporting is a crucial aspect and I want to support ease of use. I'm thinking of scaling it way back for the new release and only including the most basic fundamental information that pretty much everyone will need and leaving the business object code behind reports for the edge cases.
However I'm wondering if I'm not off on a tangent completely and how people normally handle this kind of thing.
Any ideas or pointers or information on how you handle complex reporting and end user customization would be greatly appreciated.
Hi,
I haven't used DataDynamics ActiveReport in the last years but this product have some nice features like:
"ActiveReports allows you to host the report designer in your application and distribute it royalty free. It also allows end-users to edit reports and to save and load report layouts. In addition, it allows you to monitor and control the design environment and customize the report's look and feel to meet the needs of your end users."
I know of a couple of projects that have generated the RDLC files "on the fly" for easy reporting (since it is just XML) but I would recommend that fir any advanced reporting.
So, might be worth to look up ActiveReport.
Hi Jonny, I am familiar with ActiveReports, it isn't remotely as powerful or flexible as DevExpress XtraReports which also has an end user report designer (had it first of all the .net reporting components) and supports code behind and report formats stored as xml etc etc.
The reporting component isn't the issue at all though, sorry if I gave that impression, it's not what I'm talking about here.
Well... I guess the first question is whether your users will accept your step back in reporting functionality. You say that you built your existing functionality based on the requests of users; so what happens when you release a new version that has much more limited reporting capabilities?
There have been a few discussions surrounding reporting using CSLA BO's, and as you've obviously seen, it's possible. It's becoming more possible with newer tools, but you're still somewhat limited if that's the route you want to go. And I think there's a reason for that.
I don't think reporting straight off BO's is a terribly good idea.
I think you have to separate your "application experience" from your "reporting experience". Yes, the two pieces are most often contained within the application. But they are still two fundamentally different things. I think that if you try and meld them, you're only going to make your life harder - and, as you've already mentioned, created a pretty high floor for your users.
Presuming that you can deal with the "step back" issue, I would most definitely not use BO's as your basis for reporting. If it's really that complicated, then I'd look into one of the reporting tools out there (Business Objects, SSRS designer, etc.) and formally admit/accept the complexity of the reporting requirement. If you're still gonzo about using BO's, then I'd honestly consider creating a separate read-only BO hierarchy for your reporting needs.
HTH
- Scott
We've considered it very carefully and decided we want the best possible product, not a compromised one that tries to be everything to everybody. That being said we are in no way taking away functionality asked for, quite the opposite, we're trying to make it easier and cleaner just not a mish mash like it is now.
This is all about edge cases, for the great majority of our users our stock reports are fine and this is a very mature product, at this point we have a pretty good idea what 90% of our users are going to want "out of the box" and provide it.
No I agree, not off the normal ones, I'm thinking of lightweight read only ones for reporting purposes.
I agree. It's an age old problem. I think what I need to do is separate the concept of the power reporting users from the regular users more than anything then think of the solution for them.
For the majority of users it's a non issue, they might go in and put in their logo on a stock report, that's about it. Something that's dead easy to do. It's the outliers I'm thinking about, there's just no limit to what data people want available in the report designer and exposing business objects seem to resolve the issue.
The only other way I can think of going is exposing the database directly to sql queries somehow but that seems dangerous and far more complicated than nice clean business objects with their hierarchy already filled in that mirror what they see in the user interface.
It is in a MS sql server database so they could just go directly to the db with any reporting tool of their choice if they *really* need to get serious.
I guess it boils down to making sure we provide enough stock reports and some good "dashboards" with graphing capabilities for data analysis.
It's a whole area as you say almost an entire domain on it's own apart from the rest of the app. Perhaps what I need to do is write an article about it on a site like CodeProject.com and have everyone tear it apart to get more ideas! :)
Thanks Scott it does help, cheers!
Well... it would seem that you need to answer the "80/20 question" (or 90/10 in your case):
How much work do you want to put in to manage that final 10%? Because, as you've noted, it's a pretty steep curve. To be honest, very few people do that, because of the complexity involved. Most often, the payoff isn't great enough.
I certainly wouldn't suggest providing direct access to the database, even if it's only SELECT rights. Many companies consider their database schema intellectual property, and for as complicated as your BO hierarchy is, it's highly likely your database schema is worse. Most companies do not have business employees that are SQL experts, and Excel/Access wizards can only go so far. Of course, I don't know your customer base, so that may be workable for you. But it isn't very common.
I realize this isn't really an answer, except to say that I would think long and hard before tackling your "edge cases" directly in your app. Managing the complexity, while hiding it from everyday users, is practically the definition of a non-trivial problem.
HTH
- Scott
All good points, thank you for taking the time Scott, that really helps and gives me some food for thought.
Cheers!
Copyright (c) Marimer LLC