|
|
5 回复 | 直到 14 年前
|
1
4
我认为报告只是数据的另一个视图,而不是一个视图/模型/控制器(好吧,可能是一个视图和控制器)。 我们让报表(内置于sql2008reportingservices)使用应用层中的一个服务来获取数据(按照我们的标准,数据访问在存储库中)。这些函数可以执行一个简单的查询或处理非常复杂的处理,这将是报表环境或存储过程中的一个噩梦。在实践中,我们发现这只需要编写一些一次性的存储过程,随着系统的不断增长,这些存储过程将成为维护的噩梦。 将报告简单地视为一次性的或不集成到应用程序设计中是一个巨大的错误。 |
|
|
2
2
报告是至关重要的。报告对于将在一个系统中收集到的价值分享给外部用户(例如,不直接使用该系统的用户(例如,销售数字的管理))至关重要。因此,报告不仅仅是显示事实和数字,而且是几乎所有推动商业活动的系统的核心。 至少更先进的系统允许您增强它们:使用您自己可重用的“控件”。即使是后退的方法也可以实现——只要使用正确的插件。有一次我写了一个系统,从报告中发送电子邮件,因为系统不允许更改。它起作用了——尽管它不是故意这样使用的;) 报表是应用程序的重要组成部分,如果您为客户更改报表,您将获得很大的自由。有时候你会想出比当初建立系统时想象的更多的可能性。 所以对我来说,报告是系统的一部分。 |
|
|
3
1
报告是你应用程序的一部分,但因为它们通常是用户对数据捕获用户界面(比如说,你的数据捕获用户界面)有很强的想法的东西,所以我会牺牲纯洁性,以方便/快速地交付,并返回到“真正的”编码…-) 一旦你做了一个报告,用户想要另一个或改变颜色或可选分组或更多的过滤或…一些能让你远离刺激的东西…所以我不会破坏保持纯洁的肠子。 |
|
|
4
1
这的确是一条细线。您不想花费太多时间构建报表(用户希望您随时更改报表),但您不想通过将业务逻辑放入报表中来复制逻辑!通过我们在datadynamics的报告产品,我认为我们已经在这两个折衷方案之间达成了一个愉快的折衷方案。 通过使用objectdataprovider(请参阅下面的链接了解更多信息),您可以将报表直接绑定到业务对象(普通的旧对象),这样就不必绕过业务层来获取数据。同时,我们提供了一种引用和使用报表中其他库中函数的方法。这样,如果您已经配置了一些代码来执行一些业务逻辑计算,则可以直接在报表中重用这些函数。你也可以在下面的链接中看到一个例子。
斯科特威利克 数据动态/图形 |
|
|
5
1
我一直使用报表的方式是将部分报表视为代码库的一部分,并与应用程序一起存储在源代码中。在某些情况下,报表比应用程序更重要,因为管理层根据报表数据做出业务决策,错误的信息可能导致他们取消产品线、取消活动或解雇销售人员。显然,这在很大程度上取决于您的管理和应用程序。 关于保持模型的一致性,这是一个比较棘手的问题。确保报表和应用程序之间模型一致的一种方法是使用存储过程(或视图)检索数据,具体取决于应用程序的体系结构。 |
推荐文章