问题
When do we use client side reporting and when do we use server side reporting?
Which reporting is best practice (client/server)?
This pertains to SSRS reporting.
回答1:
Well... client side reporting you'd use if you've got something like a winforms client that you can't guarantee will have constant access to the data source. It might have a set of data cached on the client side which you need to report on even if the connection to the server is unavailable.
Server side reporting you'd use in the scenario where you either need to simplify the report distribution and deployment as you just deploy the reports to one place and everyone can access them. This has the downfall of always requiring a connection be available to the server
回答2:
Client side reporting is also handy when you have a client gathering data from very different sources. We have an in-house corporate application that calls internal services to get data from financials as well as our separate production database, and it combines them into a single dataset which it passes to a ReportViewer control.
From an aesthetic point of view, it's nice to integrate reporting into an application so that the user doesn't feel that they're leaving the app to print or export the app's data.
回答3:
Client site reporting
If one of the following is true then you should use client site reporting:
- If you have the data only on the client and not in the network or on the server. This is mostly true for desktop applications.
- There is no server (Home systems).
Server site reporting
If one of the following is true then you should use server site reporting:
- The data is on the server or on a static place in the network.
- You only have thin clients.
- The reporting should be scheduled.
- The license cost for a single server is smaller than for many desktop installations.
- Report templates are shared and can change frequently.
回答4:
It depends what you call "server" in this case. As you mention SSRS I am assuming you consider the database (SQL Server) as the server.
It all depends on the application/project structure and requirements. If you have a database that contains also the business logic (store procedures) and you simply want to query data and display/export it, then SSRS is handy.
However if you have a web application with your persistence layer (database) that simply stores information and ensures the information is consistent, but then your business logic is for example in a Web API (i.e: a RESTful API project) that queries/maintains the database data (CRUD) and adds some logic and then responses to HTTP requests with the results/information requested (i.e: with JSON) to a rich front-end, then I would add reporting functionality at client-side (front end) with for example a Javascript library executed in the browser that is able to display the retrieved data in whichever way, it is able to export it to a DOC, Excel, Email it, etc.
Separation of concerns for a typical Web Application:
- persistence layer (Database) to store information and guarantee consistency
- business layer (Back end RESTful API) to do all the smart things on the resources, calculations, authentication, authorization for each HTTP request.
- Rich front-end (Javascript + HTML + CSS) to interact with the user and request/display information to the back-end. As part of the concern of displaying information, this front-end would also generate reports.
来源：https://stackoverflow.com/questions/137422/using-client-side-reporting-vs-server-side-reporting