最近，我有一个项目，其中我必须将一些数据从特定的软件系统获取到 portlet。 该软件使用数据库，我花了相当多的时间对我想要的数据进行建模，然后创建一个 Web 服务，以便我的 portlet 可以获取信息。
然后我突然意识到我在浪费时间。 我抓住了 BIRT，将其放入 portlet 中，然后编写了一些直接从数据库中获取必要数据的报告。 我一个下午就完成了。
我知道报道是一条单行道，但这让我开始思考。 报告工具对于根据实际数据创建报告非常有效（废话），但是当您这样做时，您会绕过模型，除非在简单的情况下，模型并不是数据库中存在的数据的直接表示。
如果您正在编写数据密集型应用程序并需要执行重要报告的能力，您是否会绕过您的应用程序并使用 BIRT 或 Crystal Reports 等工具？ 作为整个流程的一部分，您如何管理这些工具？ 您是否认为您撰写的报告是您申请的一部分并如此对待它们？ 报告是一个视图、一个模型和一个控制器（如果你愿意的话），所有这些都在一个大混乱中，你如何处理、解释和计划呢？
修改后的问题：报告可能会执行一些业务计算，在完美的世界中您希望将其包含在应用程序中。 这可能会导致返回给用户的信息不匹配。 另一方面，报告工具使收集和显示信息变得如此容易，以至于很难采用纯粹主义者的方法并在应用程序内完成所有操作。 是否有任何好的技术可以确保报告中的数据与常规 GUI 中可能显示的数据相匹配？
Recently I had a project in which I had to get some data from particular software system to a portlet. The software used a database, and I spent a fair bit of time modeling the data I wanted and then creating a web service so that my portlet could grab the information.
Then it suddenly struck me that I was wasting my time. I grabbed BIRT, tossed it into a portlet, and then just wrote some reports that directly grabbed the necessary data from the database. I was done in an afternoon.
I understand that reporting is a one way street, but this got me thinking. Reporting tools can be very effective for creating reports (duh) from your actual data, but when you're doing this you're bypassing your model which except in simple cases is not a direct representation of your data as it exists in your database.
If you're writing a data-intensive application and require the ability to perform non-trivial reporting, do you bypass your application and use something like BIRT or Crystal Reports? How do you manage these tools as part of your overall process? Do you consider the reports you write as being part of your application and treat them as such? A report is a view and a model and a controller (if you will) all in one big mess, how do you deal with and interpret and plan for that?
Revised question: it's possible and even common that a report will perform some business calculations that in a perfect world you would like to have contained in your application. This can lead to a mismatch of information given back to the user. On the other hand, reporting tools make it so easy to gather and display information that it's hard to take a purist's approach and do everything from within the application. Are there any good techniques for ensuring that the data in your reports matches the data that you might be showing in the regular GUI?
发布评论
评论（5）
我将报告视为数据的另一种视图，而不是视图/模型/控制器的结合体（好吧，也许是视图和控制器的结合体）。
我们的报告（内置于 sql 2008 报告服务中）使用应用程序层中的服务来获取数据（符合我们的标准，数据访问位于存储库中）。 这些函数可以执行简单的查询或处理非常复杂的处理，这在您的报告环境或存储过程中将是一场噩梦。 在实践中，我们发现这并不需要比编写一些一次性存储过程更长的时间，随着系统的不断发展，维护这些过程将成为一场噩梦。
将报告视为一次性的或不将其集成到应用程序设计中是一个巨大的错误。
I see reporting as simply another view on the data, not a view/model/controller in one (well, maybe a view and controller in one).
We have our reports (built in sql 2008 reporting services) consume a service in our application layer to get data (keeping with our standard, that data access is in a repository). These functions could do a simple query or handle very complex processing that would be a nightmare in your reporting evironment or a stored procedure. In practice, we find this takes no longer than coding up some one-off stored procedure that will, as your system grows and grows, become a nightmare to maintain.
Treating reporting as simply a one-off or not integrating into your application design is a huge mistake.
报告至关重要。 报告对于将一个系统中收集的值共享给外部用户至关重要，例如不直接使用该系统的用户（例如销售数据的管理）。 因此，报告不仅仅是显示事实和数据，而且是几乎每个商业广告系统的核心内容。
至少更先进的系统允许您增强它们：使用您自己的可重复使用的“控件”。 如果您使用正确的插件，甚至可以实现回退。 有一次我编写了一个系统来从报告中发送电子邮件，因为该系统不允许更改。 它起作用了 - 尽管它不应该以这种方式使用；）
报告是应用程序的重要组成部分，如果您使报告可以为您的客户更改，您将获得很大的自由。 有时，您会想到比最初构建系统时想象的更多的可能性。
所以，是的，对我来说，报告是系统的一部分。
Reporting is crucial. Reporting is mostly crucial to share values collected in one system to external users, e.g. users not directly using the system (eg management for sales figures). So reporting is a lot more than just displaying facts and figures and is something central to almost every system that drives a commercial.
At least the more advanced systems allow you to enhance them: with your own reusable "controls". Even a way back can be implemented - if you just use the correct plugins. Once I wrote a system to send emails out of a report, because the system did not allow for change. It worked - though it was not meant to be used that way ;)
Reports make a good part of the application, and you gain a lot freedom if you make reports changeable for your customers. Sometimes you come up with more possibilities than you thought of when you built the system in the first place.
So yes, for me reporting is part of the system.
报告是你的应用程序的一部分，但因为它们通常是用户比你的数据捕获 UI 有强烈想法的东西，所以我会为了方便/交付速度而牺牲纯度并回到“真正的”编码...... :-)
一旦你完成一份报告，用户就想要另一个报告，或者更改颜色或可选分组或更多过滤或......一些让你远离更奇特的东西的东西......所以我不会崩溃保持纯度。
Reports are part of your app but because they are generally something a user will have strong ideas about than, say, your data capture UI, I'd sacrifice purity for convenience/speed of delivery and get back to "real" coding... :-)
As soon as you've done a report, users want another one or change the colour or optional grouping or more filtering or... something that takes you away from whizzier stuff... so I don't bust a gut maintaining purity.
这确实是一条很好的界限。 您不想花费太多时间构建报告（无论如何，用户希望您一直更改），但您不想通过将业务逻辑放入报告中来重复逻辑！ 通过我们 Data Dynamimcs 的报告产品，我认为我们已经在这两种权衡之间找到了一个折中方案。
通过使用 ObjectDataProvider（有关详细信息，请参阅下面的链接），您可以将报表直接绑定到业务对象（普通旧对象），这样您就不必绕过业务层来获取数据。 同时，我们提供了一种在您的报告中引用和使用其他库中的函数的方法。 这样，如果您已经配置了一些代码来执行一些业务逻辑计算，您可以直接在报告中重用这些函数。 您也可以在下面的链接中看到这样的示例。
Scott Willeke
数据动态 / GrapeCity
This is a fine line indeed. You don't want to spend too much time building reports (that users want you to change all the time anyway) but you don't want to duplicate logic by putting business logic into your reports! With our reporting products at Data Dynamimcs I think we have reached a happy medium between these two tradeoffs.
By using the ObjectDataProvider (see links below for more info) you can bind the report directly to business objects (plain old objects) so you don't have to bypass your business layer for getting data. At the same time we provide a way to reference and use functions from other libraries in your report. This way if you have some code configured already to do some business logic calculations you can reuse those functions directly within your report. You can see an example of this in the links below too.
Scott Willeke
Data Dynamics / GrapeCity
我一直使用报告的方式是将部分报告视为代码库的一部分，并与应用程序一起存储在源代码中。 在某些情况下，报告比应用程序更重要，因为管理层根据报告数据做出业务决策，错误的信息可能会导致他们取消产品线、取消营销活动或解雇销售人员。 显然，这很大程度上取决于您的管理和应用程序。
关于保持模型的一致性，这是一个有点棘手的问题。 确保报表和应用程序之间模型一致的一种方法是使用存储过程（或视图）来检索数据，具体取决于应用程序的体系结构。
The way I've always worked with reports is to consider part reports as part of the code-base, and stored in the source along with the application. In some contexts, reports are more important than the application, in that management makes business decisions off of report data, having the wrong information can cause them to cancel a product line, cancel a campaign, or fire a sales person. Obviously, this depends highly on your management and your application.
Regarding keeping your model consistent, this is a bit trickier question. One way to ensure consistent model between reports and your application is to use stored procedures (or views) to retrieve data, depending on your application's architecture.