This is a nontrivial question about maintenance of a legacy application myself and two other developers support. We are not the original developers,and the code base is 300,000 lines of MFC and business logic tightly coupled together. We don’t know every single line of code 100%.
We do know the code behind the major components,and we know that it’s poorly written. Our objective is to refactor the application out of 1995 and into 2010. Between the three of us there is (in aggregate) enough experience in software architecture and database design for us to fix the components that are poorly architected in code or incorrectly modelled in the database,but we don’t have a lot of experience with modern reporting systems. Thus my question (once you get to the end of it…) is about reporting systems.
For anybody who reads this entire post,I am appreciative of your time. For anybody who reads this post and replies with solutions,experience (or sympathy!),I am both appreciative and thankful.
在工作中,我继承了Access 2003数据库的维护,该数据库包含大约250个报告(以及数千个支持查询),作为我们应用程序的报告引擎.
报告中都有大量的VBA用于特定格式化或将额外信息提取到报告中.出于这个原因,我们完全被锁定在Access平台中,我们不能使用像BIDS这样的工具来导入Access报表对象,而不会搞乱使报表在没有VBA的情况下显示相同.
因此,为了让自己摆脱这种Access解决方案,我们需要花一些时间来审阅每一份报告.这意味着我们希望选择最好的长期解决方案,因为无论我们选择哪个平台,我们都必须重新开发每个报告.
此外,我们的客户可以选择Microsoft Access或sql Server作为其数据库.这意味着我们所有的sql都必须考虑到最低的公分母–JET sql.我们有一些摆脱空间来放弃对Microsoft Access的支持,但我们需要为它构建一个案例.如果我们可以识别的最佳报告系统对sql Server有很强的支持,但很少或不支持Microsoft Access,这将加速我们放弃对Microsoft Access作为数据库的支持.
报告系统的整体实现非常平庸,当我们想要在我们的应用程序中显示报告时,我们启动Microsoft Access进程,找到它的窗口并将其重新显示给我们的应用程序,剥离其窗口样式然后使用Access.Application COM用于调用某些VBA以创建链接表到数据库(Microsoft Access MDB或sql Server数据库)的接口,然后打开我们想要的报表.可能该过程中唯一受支持的部分是使用公共COM接口,其余部分是丑陋的黑客.应用程序中的其他组件同样令人印象深刻.
为了“修复”我们的应用程序,我们有了一个新的开发计划,我们的应用程序开发每年分成(大约)三个部分.
> 4个月升级我们的申请,以支持我们行业的最新政府法规
> 4个月提供新的主要功能
> 4个月“整合”(修复坏了)
我们目前处于第3位(今年),我们真的希望利用停机时间来修复应用程序,重构主要组件.我们有三个开发人员,并希望在2012年底推出AppName v5.0(目前是AppName v4.12).这为我们提供了36个月的开发工作,以便在我们之前的三个合并期间对几个组件(用户界面,底层数据库结构,报告等)进行比较.我们修复的组件总和将为我们提供v5.0.
除了我们的报告引擎之外,我们已经确定了我们想要对大多数组件做什么,并且我发布了SO以期获得一些好的想法,或者至少感觉到所需的工作.
我有两个改进报告系统的想法.它们都涉及适量的工作,并且有一个考虑因素,两个解决方案都没有完全解决：除了我们开发的报告之外,我们的客户还有机会请求定制开发报告.它们是特定于客户的,我们使用他们的Access数据库,使用他们的报告对其进行扩充并将其返回给客户.有数百个独特的报告 – 如果我们关闭旧系统就无法使用. (我们最终必须关闭旧系统 – 我们不知道我们能够多长时间使用Microsoft Access窗口使其看起来像嵌入式报告.我们已经有两个不同的代码Access 2003和2007的路径.如果我们无法破解Access 2010的代码路径并且所有客户都必须使用Access 2007,该怎么办？)
对于这两种想法,目的是停止支持我们当前的报告系统,让它在没有维护的情况下运行.也许我们可以破解Access 2010和Access 2014支持,并且开发的客户报告继续推出5年以上.随着时间的推移,我们会将旧的Access数据库中最常用的报告迁移到新格式中.
想法1：Microsoft.Reporting.WinForms.ReportViewer
The first idea is to write a wrapper around the
ReportViewercontrol as a replacement reporting engine.We’d need to move the project to C++/CLI (already on the cards),and instead of having to launch an entire process each time we needed to view a report we could simply instantiate this control. A bonus of this that the
RDLCfiles that contain the reports are much easier to version control in Subversion than the Access 2003 database we currently have (we use Visual SourceSafe because the tools to integrate SVN with Access don’t work well with the size of our Access database). The visual designer forRDLCfiles is also nicely integrated into Visual Studio.This is more of an evolutionary rather than revolutionary change to the way we do reports,the
ReportViewercontrol will take anRDLCfile that has the report layout,and our application will take care of querying the data. Because our database might be sql Server or Microsoft Access,we still have to write simple JET sql. We’re gaining better reporting (drill down looks nice),stronger authoring tools and easier version control,but is this worth the effort?
想法2：sql Server Reporting Services和带有Access Services的SharePoint 2010
The second idea is to kill Access as a database platform and migrate all our customers to sql Server (we have hosted instances of our application for those customers who don’t have the skill set to set up their own sql Server instances). Once they’re migrated we would use sql Server Reporting Services as the reporting engine,with the
ReportViewercontrol in server rendering mode.In addition to sql Server Reporting Services,I am curIoUs as to whether 07001 could be used to rapidly migrate existing Access reports into a more manageable format. We’d take the Access report that the customer uses,convert it to an Access Web Report then make it available for them on a SharePoint site. This would only be for our hosted customers,but if we find a way to deal quickly massage the VBA out of customer reports we could churn through the several hundred custom reports our customers have.
I’m also interested in the ability to use an Access Web Navigation Form to act as a portal to all our reports. We’d host a web browser control inside our application which would give customers access to their own reports and to our standard suite.
We’d get all the benefits of Idea #1 plus the ability to write in full Transact sql,a reports portal,and (hopefully) a reasonable upgrade path for customer’s proprietary reports.
所以,我的问题是：我是否采取正确的方式？这些可行的解决方案适用于现代报告系统,还是可笑的？我们强烈希望在我们的应用程序处理数据的客户端呈现模式中使用ReportViewer控件,或者在与sql Server结合使用的服务器呈现模式中使用ReportViewer控件 – 但是是否有像Crystal Reports这样的报告系统可以提供更好的报告和更好的迁移路径我们的旧版Access报告？
如果你有36个月的开发时间,你会怎么做？
解决方法
非常有趣的是你如何谈论一个15岁的报告作家.那时,Access报告编写者已经超越了最先进的水平.它比行业中的其他所有领先一英里.即使在今天,许多竞争报告编写者也没有子报告的概念,它允许对关系数据进行建模,而不必求助于代码甚至sql.然后,投入可编程VBA,结果是非常独特和强大的.
对于2007年的访问,报表编写者在布局控件方面获得了一些更好的升级,但这对此没什么帮助.
而且,对于2010年,我们现在可以在子表单控件中显示报表.添加此功能是为了便于使用新的访问导航控件. Access 2010具有新的Web浏览器控件(在表单或报表中工作),还有一个新的导航控件.您的帖子暗示新的导航控件和Web控件在某种程度上相互关联,但它们完全不同.
新的Web浏览器控件和导航控件都可以在Web应用程序或100％仅客户端应用程序中使用.导航控件非常好,因为您可以通过将报表拖放到导航控件上来构建导航控件,以构建可供选择的报表列表(它非常简单,漂亮).通过这种导航控件,我们实际上可以为报告构建一些很好的向下钻取类型的接口.
正如您在2010年访问中所述,我们现在可以通过Web发布访问报告,此功能基于sql Server报告服务(它们是RDL报告).但是,这里的两个重要问题是Web报告中不允许使用VBA.而且,我还指出,内置于访问中的自动转换实用程序不会将现有报告转换为基于Web的报告.因此,要构建将要指定并发布到Web的报表,您必须专门选择创建Web报表以实现此目标.所以这回答并清除了你的一个问题,这将帮助你将现有报告转换为sql服务器,答案是否定的.因此,Access不会帮助您将现有报告转换为基于Web的RDL报告(如上所述,Access使用RDL和sql报告来处理这些Web报告 – 这些报告也在访问客户端呈现而不进行转换).
Access通过SharePoint有一个很好的基于Web的报告的路径,Access Web也会出现在Office 365中.但是,请记住,这种能力对现有的报告没有多大帮助.
事实上,如果您要使用winforms报表查看器,我将要考虑的一件事是将现有VBA报表代码移动到哪里的变化？你没有真正提到这个问题.如上所述,这些报告的一个非常有趣和强大的功能是嵌入的VBA代码.通常会使用VBA,因为sql和RDL之类的东西不起作用,因为这些语言(sql和RDL)都不是程序代码.
我无法强调这个概念的重要性.因此,这非常意味着任何报表编写者替换意味着代码现在必须在报表的外部并移动到您的应用程序中.因此,在发布新报告时,请记住此问题,您还要发布不包含在这些报告中的新过程代码.此代码必须成为您的应用程序的一部分(因此,为了发布新报告,您将因此使用新版本的软件).
您不太可能发现允许将过程代码嵌入到报表中,就像您可以访问一样.因此,现在必须在主应用程序内和报告之外构建和维护该报告代码和逻辑.
在一天结束的时候,我应该指出一句古老的谚语,如果没有破坏,那么就不要改变它.访问已经存在了很长时间,但我们看到Redmond的人们在过去几年里对这个产品进行了大量投资,因此它没有显示出任何时候很快就会死亡的迹象.
因此,一个可能的建议是保持现状,并继续按现在的方式行事.我的意思是你声明你必须继续为此支持JET,所以你无论如何都不必使用Access的主要部分.所以,你仍然必须使用JET引擎.所以,你只是转储报告方面,你仍然使用JET数据引擎.
但是,假设做出了这个决定,我真的无法建议你应该用哪个报告作者替换访问权限.显然,对于下一个报表编写者的考虑应该有一条无缝的Web路径,即使它们现在要在桌面上呈现.如果没有网络考虑,今天进行大量投资是没有意义的.
我认为由于网络能力,sql服务器报告服务是一个不错的选择.而且,作为一个访问开发人员,我们还可以选择创建基于Web的报告,但它们也可以在桌面端的访问客户端中呈现完美(当没有服务器时,这可以正常工作,并且在将这些报告发布到Web时不存在转换问题,或在客户端使用本地).因此,即使您不使用访问权限,也要选择一些允许报表呈现桌面和Web的访问权限.
我会考虑围绕一些.net工具构建报告系统.这可能不会像现有应用程序中的嵌入式报表系统那样好,但它允许您发布新报表,并且您不必为每个发布的新报表触及现有代码库.需要解决具有过程代码的新报告的发布.您现在可以发布新报告而无需修改主应用程序,因为这些报告可以包含代码.我希望使用能够构建和发布新报告的东西,但您不必发布主要软件的新版本.您可能不再将代码嵌入到报表中,但是您需要将其放在某处,并希望在主应用程序之外.
